Fallout→Fallout upgrades break at compile time with no signposting to fallout-migrate (10.3→10.4 CS0246 on Project)

@
## Problem

Upgrading a consumer build from `Fallout.Common` 10.3.49 to 10.4.0-rc.5 fails to compile:

```
Build.cs(160,5): error CS0246: The type or namespace name 'Project' could not be found
```

Reproduced on FluentAssertions (a real consumer already on Fallout 10.3.49) changing **only** ``. Exactly 1 error, 0 warnings.

`Solution` and `Project` moved from `Fallout.Common.ProjectModel` to `Fallout.Solutions`. The transition shim in `src/Fallout.Common/ProjectModel/TransitionShims.cs` **is** shipped in rc.5, but is shallow by design — verified from the rc.5 package's own XML docs, it contains only:

```
T:Fallout.Common.ProjectModel.Solution
T:Fallout.Common.ProjectModel.SolutionAttribute
```

`Project` is deliberately not shimmed. So `using Fallout.Common.ProjectModel;` keeps compiling and `Solution` keeps resolving — the build breaks only where the consumer touches `Project`. The rename is **not** half-applied; this is the documented shim ceiling.

`fallout-migrate` 10.4.0-rc.5 already has the rewrite rule (`RewriteCsFilesStep.projectModelNamespace`, matching both `Nuke.` and `Fallout.` prefixes) and **fully fixes this**. Verified end-to-end: running it on the already-Fallout FluentAssertions repo rewrote `using Fallout.Common.ProjectModel;` → `using Fallout.Solutions;` and the build went green.

**So the defect is not a missing rewrite — it is that nothing leads a consumer to the fix.**

- `fallout-migrate`'s own description is "Migrate a NUKE consumer repo to Fallout". A maintainer bumping 10.3 → 10.4 has no reason to think it applies to them.
- Its other steps are NUKE-specific (`RenameNukeDirectoryStep`, `RewriteBootstrapScriptsStep`, `ResolveFalloutVersionStep` pinning "latest stable in-major").
- The consumer just sees CS0246 and hand-fixes it. The one-line fix is `using Fallout.Common.ProjectModel;` → `using Fallout.Solutions;`.

Secondary, same run: on an already-Fallout repo `RewriteCsprojsStep` strips the explicit `System.Security.Cryptography.Xml` pin (see #618) and leaves its explanatory comment orphaned above nothing, plus de-indents the closing ``/`` tags.

## Outcome

A consumer bumping a Fallout version either does not break, or is told exactly what to run.

## Acceptance criteria

- [ ] 10.4.0 release notes / upgrade guide state that `Fallout.Common.ProjectModel` → `Fallout.Solutions` and that `fallout-migrate` performs the rewrite
- [ ] Reframe `fallout-migrate` so a Fallout→Fallout version bump is an advertised use case, not just NUKE→Fallout (see the version-wise migration proposal — separate issue/PR)
- [ ] Decide: extend the shim to cover `Project`, or leave the ceiling and rely on documentation + migrate
- [ ] Consumer-upgrade smoke test (10.3.x source compiled against the next minor) so this is caught before GA — `fallout.canary` is the natural home
- [ ] Fix the orphaned-comment / de-indentation fallout in `RewriteCsprojsStep`

## Correction

The original text of this issue claimed there was no transition shim, no type-forwarding, and no `fallout-migrate` rule, and carried a `breaking-change` label. **That was wrong** — it was based on a local `release/v10.4` ref that was 32 commits behind the `v10.4.0-rc.5` tag. Both the shim and the migrate rule exist at the tag. Body corrected and the label removed; the compile break and the signposting gap are real and reproduced.
@