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

[ChrisonSimtian]

Stacked on #254 (base: `feat/inline-vs-solutionpersistence`). After #254 merges, this PR re-targets to `main` and the diff shrinks to just the consumer-projects content.

The whole point of this PR is to prove #254 doesn't break consumers. If these three consumer projects compile against the #254 source tree, the shim has done its job and #254 is safe to merge.

Summary

Three small build-project consumers under `tests/Consumers/`:

• `Nuke.Consumer` — pre-rename NUKE-shape `class Build : NukeBuild`, `[Solution]`, `Target` via the `Nuke.Common` / `Nuke.Build` / `Nuke.Components` transition shims. Includes a documented `using Target = Fallout.Common.Target;` alias because the shim generator skips delegates by C# language limit (SHIM002).
• `Fallout.Consumer.Local` — direct `ProjectReference` to this repo's local source. Tracks HEAD, catches breakage in the current PR.
• `Fallout.Consumer.NuGet` — `PackageReference` to nuget.org, pinned to 11.0.8 (pre-feat(persistence)!: inline vs-solutionpersistence; rename SolutionModel → Solution; namespace cleanup #254 release), with `ReplacePackageReferences=false` so it actually resolves against published packages. Catches packaging issues + upgrade-direction breakage when bumped after a release.

All three are in `fallout.slnx` — `dotnet build fallout.slnx` (the existing CI gate) compiles them. Compile failure ⇒ a consumer-facing API broke.

Why no runtime smoke tests

Initial design had a `Consumers.SmokeTests/` xUnit project that spawned each consumer via `dotnet run` and asserted exit code 0. That approach hits a Fallout framework runtime requirement: `FalloutBuild.cctor()` enumerates `Host` subclasses and reflects for a static `IsRunningHost` property — minimal consumers that don't pull in the full Fallout MSBuild props/targets (`Fallout.Common.props`, `Fallout.Common.targets`) trigger a `System.ArgumentException: Host type 'Host' defines no property 'IsRunningHost'` at activation.

Reproducing the full build-app environment for a smoke consumer is meaningfully more setup than the test's marginal value justifies (the compile-time check catches the ~95% case). The README documents this and points at how to revisit if needed.

Test plan

• `dotnet build fallout.slnx` — 0 warnings, 0 errors. All three consumer projects compile against the feat(persistence)!: inline vs-solutionpersistence; rename SolutionModel → Solution; namespace cleanup #254 changes.
• `dotnet test fallout.slnx --no-build` — all suites green (StronglyTypedSolutionGenerator verified snapshot regenerated for the +3 new projects).
• CI green on this PR (confirms above against a clean machine).
• On any future PR that breaks a consumer-facing API, one of these three projects fails to compile and CI catches it.

Coordinates with

• feat(persistence)!: inline vs-solutionpersistence; rename SolutionModel → Solution; namespace cleanup #254 — the vendor-fork-elimination PR this is stacked on. These tests are the proof that feat(persistence)!: inline vs-solutionpersistence; rename SolutionModel → Solution; namespace cleanup #254's shim work preserves the consumer contract.
• Update Nuke→Fallout codefix to map Common.ProjectModel → Solutions for v11 #253 — codefix follow-up. The `Fallout.Consumer.NuGet` will need its pin + Build.cs namespaces bumped to use `Fallout.Solutions` after the next release ships the new namespace surface, which will exercise the migration path.

[ChrisonSimtian]

Stack ordering was wrong (consumers built on top of the breaking-change PR, so they tested against the new API rather than catching the change). Superseded by a new PR off main with pre-#254 namespaces — see follow-up. #254 will rebase on top of that.