Improve project build signing and publish timing

[PrzemyslawKlys]

Summary

• make assembly signing default to first-party build outputs only, with explicit SignDependencyAssemblies opt-in for copied dependency assemblies
• include first-party assemblies even when a project lives under an Internals directory, instead of skipping by path name
• include every evaluated target-framework assembly name when signing multi-target projects with conditional AssemblyName metadata
• make package timing honest: project logs now report the package workflow, while phase logs measure build-before-sign, output resolution, assembly signing, pack, package signing, publish, and GitHub upload separately
• reduce repeated work by reusing a completed project package build for module publish instead of rebuilding/repacking/resigning/rezipping for NuGet and GitHub publish
• require all reused NuGet or GitHub package artifacts to still exist before publishing from a prior package build; partial artifact sets now fall back to the normal publish path
• guard reused publish lanes so empty earlier build results fall back to the normal publish path, and preserve configured PublishFailFast for reused NuGet/GitHub publishes
• prevent NuGet publish from continuing after required package signing fails, including non-fail-fast runs
• preserve explicit package order when publishing reused package outputs, so dependency-first order from the caller is not alphabetically reshuffled
• avoid repeated signing discovery by resolving conventional SDK output folders first and passing explicit file paths to the signing service
• probe evaluated TargetDir for target frameworks that do not have conventional output folders, so custom output paths are still included in assembly signing
• prefer evaluated AssemblyName when signing first-party assemblies, so conditional/imported project metadata signs the produced assembly instead of a raw XML fallback
• reduce signing process overhead by batching assembly signing requests and signing all produced NuGet packages with one dotnet nuget sign invocation
• keep PackStrategy=MSBuild as the build-once path: batch build selected projects, sign outputs, then pack with NoBuild=true
• skip stale GitHub release reuse preflight when timestamped tag templates are intentionally volatile

Validation

• dotnet test .\PowerForge.Tests\PowerForge.Tests.csproj -c Release --no-restore --filter "DotNetRepositoryReleaseServiceTests|DotNetNuGetClientTests|ProjectBuildPreparationServiceTests|NuGetPackagePublishServiceTests|ModulePipelinePackageBuildTests|ProjectBuildWorkflowServiceTests|ProjectBuildGitHubPreflightTests|PowerForgeProjectCmdletTests|ProjectBuildPublishHostServiceTests" (110 passed)
• dotnet build .\PowerForge.PowerShell\PowerForge.PowerShell.csproj -c Release -f net472 --no-restore --nologo
• git diff --check

OfficeIMO timing evidence

• full OfficeIMO no-publish release run on this branch: 653.933s for 43 package workflows and release zips
• phase totals from that run: build-before-pack 66.3s, output directory resolution 0.048s, assembly signing 391.2s, derived raw dotnet pack time 44.0s, release zip 27.0s, NuGet package signing 132.0s
• earlier full OfficeIMO publish run on the first PR version: 948.775s total, including 1.5m NuGet publish and 2.0m GitHub upload; release execution before GitHub upload was 13.6m
• output directory resolution was previously a visible 52.0s bucket; conventional path resolution removes that repeated MSBuild property probing for normal SDK outputs
• three-project OfficeIMO slice after fast output resolution: 49.119s, versus 58.833s for the earlier per-project slice

Notes

• signing remains the largest release cost because timestamping is paid per signed file: about 391s for OfficeIMO assembly outputs and about 132s for 43 NuGet packages in the measured no-publish run
• parallel package signing was tested and rejected because concurrent timestamp requests made the DigiCert timestamp endpoint fail; this PR keeps the safer single-process batch signing path

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 22aeb639df

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c9f4f56f78

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7f0d2d20d8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6e89eb4a83

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".