Migrating against 10.3.49 produces a repo that fails restore with NU1903 (resolved by 10.4.0 GA)

@
## Problem

Running `fallout-migrate` today produces a consumer repo that cannot restore. Two behaviours combine:

1. `ResolveFalloutVersionStep` pins the latest **stable** release within the tool major → `10.3.49`. `Fallout.Common` 10.3.49 depends on `System.Security.Cryptography.Xml` **10.0.6**, which carries five high-severity advisories (GHSA-23rf-6693-g89p, GHSA-8q5v-6pqq-x66h, GHSA-cvvh-rhrc-wg4q, GHSA-g8r8-53c2-pm3f, GHSA-mmjf-rqrv-855v).
2. `RewriteCsprojsStep` deliberately strips the consumer's explicit `System.Security.Cryptography.Xml` pin (intentional, #217, to avoid NU1605 downgrade errors).

So the migration removes the consumer's protection *and* pins them to the vulnerable transitive. On a repo with `TreatWarningsAsErrors`, `./build.ps1` fails restore immediately with 5× NU1903.

Reproduced end-to-end on FluentAssertions at its last NUKE commit (`3eacba9^`) with the 10.4.0-rc.5 tool. Corroborating evidence: FluentAssertions' own hand-done migration had to re-add `System.Security.Cryptography.Xml 10.0.10` with a comment naming exactly this NU1903.

## Outcome

**No code change requested — 10.4.0 GA resolves this.** `Fallout.Common` 10.4.0-rc.5 already depends on the patched `System.Security.Cryptography.Xml` **10.0.10**, and `ResolveFalloutVersionStep` picks the latest stable in-major, so once 10.4.0 ships the migration will pin 10.4.0 and restore cleanly.

Filed to record the diagnosis so the 10.4 release notes can point consumers at it, and so the interaction is on record if the strip-the-pin behaviour is ever revisited for older targets.

## Acceptance criteria

- [ ] Confirm a fresh `fallout-migrate` run against 10.4.0 GA restores cleanly on a `TreatWarningsAsErrors` consumer
- [ ] Close on 10.4.0 GA publish
@