Add ClickOnce publish-layout resolution - #1051

Part of #1049.

Summary

• Add dormant ClickOnce publish-layout resolution through:
  • ClickOnceApplicationPublishLayoutResolver
  • ClickOnceDeploymentPublishLayoutResolver
  • ClickOncePayloadResolver
• Represent the resolved layout with strongly typed models:
  • ResolvedClickOncePublishLayout
  • ResolvedClickOnceDeployment
  • ResolvedClickOnceApplication
  • ResolvedClickOncePayload
  • ResolvedClickOnceAdjacentExecutable
• Report resolution failures through ClickOncePublishLayoutResolutionException while preserving ordered manifest diagnostics.
• Read deployment and application manifests through the preservation-safe typed manifest-reader API for every resolution read.
• Require a deployment manifest model to expose exactly one assembly reference, no file references, and an entry point that is the same non-prerequisite, non-optional reference. Inspect the preserved deployment XML to reject resource-fallback attributes that ManifestUtilities neither models nor preserves. Reject unsupported shapes before file resolution so ManifestUtilities or mage.exe cannot reorder or rewrite them before signing.
• Reject rooted deployment-entry-point and application-payload target paths before resolution because they cannot be represented beneath a staging root. Preserve relative target paths, including parent traversal, for containment validation against the eventual staging root.
• Resolve the deployment manifest's referenced application manifest, then resolve physical application payloads using the specified mapping and directory-fallback rules.
• Preserve each payload's source and manifest reference while snapshotting its target path. ResolvedClickOncePayload validates that the source filename matches the target filename, with or without exactly one additional .deploy suffix, and derives IsFileExtensionMapped from that relationship.
• Model adjacent executables separately with a constrained setup/launcher kind. ResolvedClickOnceAdjacentExecutable derives its target path from its source filename and validates the filename against its kind.
• Discover only applicable adjacent setup.exe and unreferenced root-level Launcher.exe files; referenced launchers remain application payloads.
• Use neutral "deployment manifest" and "application manifest" terminology in user-facing resolution errors.
• Add coverage for deployment-reference validation, required and optional physical references, multiple versions, malformed and wrong-type manifests, mapping, fallback and diagnostic ordering, adjacent executables, VSTO layouts, target-path validation and preservation, and model invariants.

Intentional scope boundary

This PR resolves and models the publish layout only. It does not register the resolvers with dependency injection and does not change production signing behavior or the CLI surface. Diagnostic text may reference the planned --clickonce-signing-version 2 --no-update-clickonce-manifest option, but the resolvers remain dormant until signer integration adds that option.

Staging, relative-path containment validation, copying, temporary .deploy suffix removal and restoration, manifest metadata updates, signing-operation coordination, and signing remain deferred to the signer-integration work. Resolution rejects rooted target paths but does not rewrite or remap accepted relative paths. Staging must ensure those relative paths remain within the staging directory and fail when a referenced layout cannot be represented safely.

The deployment resolver establishes that Application.Source is the file initially identified by Deployment.ApplicationManifestReference.ResolvedPath. This is a resolution-time postcondition rather than a durable model invariant because staging must redirect that mutable ResolvedPath. The staging implementation must stage Application.Source, redirect the deployment entry point to that exact staged copy, verify that it is contained within the staging directory, and only then update deployment-manifest metadata. At the start of staging, it must capture the deployment entry point's target path. Immediately before deployment-manifest metadata update and serialization, it must fail unless the live entry point is still the resolved ApplicationManifestReference, remains the sole assembly reference with no file references, and its target path still ordinally equals the captured value. It must not reconcile or serialize mutated deployment structure.

For payloads, ResolvedClickOncePayload.TargetPath is an immutable resolution-time snapshot of Reference.TargetPath, not a live projection. Staging must use that snapshot to determine the intended layout, preserve the manifest-relative meaning rather than remapping it, and bind each mutable reference's ResolvedPath to the corresponding contained staged file before updating metadata. Before computing staging destinations or collision claims, and again immediately before updating application-manifest metadata and serializing the manifest, staging must verify with ordinal comparison that each mutable Reference.TargetPath still equals its resolved snapshot. A mismatch must fail staging rather than reconcile or emit an inconsistent manifest.

The deployment-directory payload fallback is a source-discovery mechanism. Signer integration must retain an explicit mapping from every staged file to the original ResolvedClickOncePayload.Source it was staged from and copy signed bytes back to that exact source path. It must not derive copy-back destinations from staging-relative paths or reuse a directory-mirroring copy-back seam that would create a new application-directory file for a deployment-directory fallback source. Integration coverage must verify that a fallback payload is returned to its original source and that no unintended target-relative file is created.

Discovery can also produce two resolved references to one physical file: a root-level setup.exe referenced by the application manifest is classified as both a ResolvedClickOncePayload and a ResolvedClickOnceAdjacentExecutable, with both Source values identifying the same file and potentially the same target path. Signer integration must apply the same source-keyed coordinated signing operation to both references so the file is staged, signed, and copied back exactly once rather than processed as two independent operations.