test(consumers): add NUKE + Fallout consumer compatibility sentinels

[ChrisonSimtian]

Replaces #255 (closed — wrong stack ordering). This PR is based on main with the current pre-rename API shape baked into the consumer code. That makes it the breaking-change detector: any future PR that changes consumer-facing types/namespaces/attributes will conflict with the consumer code, and resolving the conflict IS the migration story.

Three consumer projects

• `tests/Consumers/Nuke.Consumer/` — NUKE-era `class Build : NukeBuild, [Solution], Target` via the `Nuke.Common` / `Nuke.Build` / `Nuke.Components` transition shims. Catches shim-coverage breakage.
• `tests/Consumers/Fallout.Consumer.Local/` — direct `ProjectReference` to in-repo `Fallout.*`. Catches in-PR breakage of the local source.
• `tests/Consumers/Fallout.Consumer.NuGet/` — `PackageReference` pinned to `Fallout.* 11.0.8` on nuget.org with `ReplacePackageReferences=false` + central package management off. Catches packaging issues + upgrade-direction breakage when bumped after a release.

All in `fallout.slnx` — `dotnet build fallout.slnx` is the CI gate.

The deliberate workflow

1. This PR lands first. `main` now has consumer sentinels reflecting today's consumer-facing API.
2. feat(persistence)!: inline vs-solutionpersistence; rename SolutionModel → Solution; namespace cleanup #254 (vendor-fork elimination + namespace rename) rebases on top of this. Its namespace changes will conflict with the consumer code on rebase. That conflict IS the breaking-change signal.
3. Resolving the conflict in feat(persistence)!: inline vs-solutionpersistence; rename SolutionModel → Solution; namespace cleanup #254 means updating `Fallout.Consumer.Local`'s csproj path + `Build.cs` namespaces to match the new `Fallout.Solutions` shape. That update is the migration story — documented in feat(persistence)!: inline vs-solutionpersistence; rename SolutionModel → Solution; namespace cleanup #254's CHANGELOG entry.
4. After feat(persistence)!: inline vs-solutionpersistence; rename SolutionModel → Solution; namespace cleanup #254 lands with consumers updated, `main` once again has consumer sentinels reflecting the (post-rename) consumer-facing API. The cycle continues for future PRs.

This works as designed only because the consumer code is frozen to a point-in-time API shape, not auto-regenerated to match new code. `tests/Consumers/README.md` documents the intent and warns against breaking that contract.

Runtime smoke tests deliberately excluded

`FalloutBuild.cctor()` enumerates `Host` subclasses and reflects for `IsRunningHost` — minimal consumers without the full Fallout.Common.props/targets environment throw `ArgumentException: Host type 'Host' defines no property 'IsRunningHost'` at activation. Reproducing the full build-app environment was meaningfully more setup than the runtime check's marginal value justified. Compile-time validation captures the breaking-change signal we actually need.

Test plan

• `dotnet build fallout.slnx` — 0 errors, all three consumers compile against current main
• `dotnet test fallout.slnx --no-build` — all suites green (StronglyTypedSolutionGenerator snapshot regenerated for +3 projects)
• CI green on this PR
• feat(persistence)!: inline vs-solutionpersistence; rename SolutionModel → Solution; namespace cleanup #254 rebased on this — expects conflicts in `Fallout.Consumer.Local/{csproj,Build.cs}` (the namespace-rename consequence). Conflict resolution becomes the documented migration step.