[Feature]: Verify that the build is actually reproducible

### Background and motivation

The build sets `EnableContinuousIntegrationBuild()` during `Pack`, with a comment saying it is "necessary for deterministic builds". But nothing ever checks that the build actually *is* deterministic. If a non-deterministic input creeps in — an embedded timestamp, an absolute path, a generated file with a random ordering — nobody finds out.

Proposal: add an optional build target that verifies reproducibility, for example by building the package twice into different directories and comparing the resulting content hashes, or by using [`dotnet-validate`](https://github.com/dotnet/sdk) style checks on the produced package.

This turns a claim in a code comment into something the build proves on every run.

### Alternative Concerns

* Building twice roughly doubles the packaging time, so this should be a separate target that CI can run on tags only, rather than part of the default flow.
* Comparing whole-file hashes can produce false failures for reasons unrelated to determinism (signing, embedded ordering). Comparing the extracted contents, ignoring known-variable entries, is more robust but more work.
* This overlaps with the build provenance attestation, which lets others verify *who* built the package. Reproducibility lets them verify they can rebuild it themselves, which is a stronger guarantee.

### Could you help with a pull-request?

No

Start at the Pack flow where EnableContinuousIntegrationBuild() is set, then identify how an optional verification target can build the package twice into different directories. Define done as a CI-invokable check that compares reproducible package content while handling known-variable entries and does not affect the default packaging flow.

Written by the indexing model from the issue text.