[P3] Execute solution-wide Nuke.* → Fallout.* namespace rename (BREAKING)

[ChrisonSimtian]

Scope

Execute the complete Nuke.* → Fallout.* rename across every axis in a single atomic PR. The Fallout brand cannot carry forward the NUKE name in any active surface — references to upstream NUKE remain only as historical attribution.

#34 (csproj filename rename) is rolled into this issue — splitting them would create an intermediate state where namespaces and assembly names disagree, complicating InternalsVisibleTo, ProjectReference paths, and the dogfooded build.

Plan and locked mapping: docs/rebrand-plan.md. Strict 1:1 prefix swap, no consolidation (locked by the bridge-package design in #35/#47).

What changes

Axis	Before	After
Namespace declarations	namespace Nuke.X.Y	namespace Fallout.X.Y
using directives	using Nuke.Common;	using Fallout.Common;
Fully-qualified type references in code, xmldoc cref, attribute strings	Nuke.Common.X	Fallout.Common.X
Folder names under src/ and tests/	src/Nuke.Common/	src/Fallout.Common/
.csproj filenames	Nuke.Common.csproj	Fallout.Common.csproj
Assembly names (default = csproj name)	Nuke.Common.dll	Fallout.Common.dll
Package IDs	Nuke.Common	Fallout.Common
ProjectReference paths in every csproj	..\Nuke.Common\Nuke.Common.csproj	..\Fallout.Common\Fallout.Common.csproj
InternalsVisibleTo attributes in AssemblyInfo.cs	Nuke.Common	Fallout.Common
_build.csproj framework refs	..\src\Nuke.Common\Nuke.Common.csproj	..\src\Fallout.Common\Fallout.Common.csproj
Solution file <Project> entries in fallout.slnx	src/Nuke.X/Nuke.X.csproj	src/Fallout.X/Fallout.X.csproj
Verify snapshots embedding FQTNs	Nuke.Common.X	Fallout.Common.X
Source-generator emitted code	Nuke.Common.*	Fallout.Common.*
GlobalTool templates (templates/Build.cs)	references Nuke.Common package	references Fallout.Common package

What's preserved (carved out)

Carried forward from #52's intentional-keep list — anything referencing upstream NUKE as a historical project stays:

• Constants.UpstreamNukeRepository / UpstreamNukeRepositoryGit — deliberate legacy-recognition constants
• Telemetry.Properties.IsCommonType legacy-NUKE assembly identification (NUKE 10.x assemblies built against the upstream RepositoryUrl keep being recognized)
• tests/Nuke.Build.Tests/GitRepositoryTest.cs + tests/Nuke.Common.Tests/GitHubTasksTest.cs — fixtures that deliberately parse nuke-build/nuke URLs
• src/Nuke.Utilities/EnvironmentInfo.SpecialFolder.cs:34 — link to historical upstream PR #825
• README / CONTRIBUTING / CLAUDE.md attribution paragraphs
• CHANGELOG.md historical entries
• build/_build.csproj line 33 — commented-out NukeExternalFiles test code

Note: the test fixture filenames tests/Nuke.Build.Tests/... and tests/Nuke.Common.Tests/... themselves do rename (to tests/Fallout.Build.Tests/... etc.). The carve-out is only their contents.

Approach

1. Inventory pass — exhaustively enumerate namespaces, project refs, assembly attributes, Verify snapshots. Catches surprises before any rewrite.
2. Folder + csproj moves via git mv so history is preserved.
3. Scripted prefix rewrite with anchored regex over .cs, .csproj, .targets, .props, .json, .slnx — anchored so we don't accidentally rewrite e.g. nuke-build/nuke URL fragments in fixtures.
4. Manual restoration of carve-outs listed above.
5. Regenerate tool wrappers (./build.ps1 GenerateTools) and Verify snapshots.
6. Build + test + dogfood — ./build.ps1 itself must run unchanged.

Done when

• grep -r '^namespace Nuke\.' src/ build/ tests/ returns zero hits
• grep -rn 'Nuke\.\(Common\|Build\|Components\|GlobalTool\|MSBuildTasks\|SourceGenerators\|CodeGeneration\|Utilities\)' src/ build/ tests/ returns only the carve-outs listed above
• All folders + csproj files renamed, git log --follow still resolves their pre-rename history
• fallout.slnx references all updated paths
• dotnet build fallout.slnx succeeds with 0 errors
• dotnet test fallout.slnx --no-build — all suites green
• ./build.ps1 runs end-to-end (dogfood test)
• All Verify snapshots regenerated and reviewed
• Single dedicated PR — no other work mixed in

Downstream unblocks

• [P5] Build Roslyn codefix for Nuke.* → Fallout.* using directives #36 (Roslyn codefix), [P5] Write NUKE → Fallout migration guide #37 (migration guide), [P5] Ship Nuke.* type-forwarding shim packages on our GH Packages feed #47 (shim packages), [P5] Build Fallout.Migrate CLI tool — automated NUKE → Fallout repo migration #48 (migrator CLI) — all blocked on this landing.

[ChrisonSimtian]

Scope split — option B

Inventory turned up additional rename axes that are best handled separately. This issue (#32) is now scoped to the mechanical rename only; type identifiers and runtime-observable names move to a follow-up.

In scope here (#32)

• Folder renames src/Nuke.X/ → src/Fallout.X/, tests/Nuke.X.Tests/ → tests/Fallout.X.Tests/
• .csproj filename renames + assembly names + package IDs
• ProjectReference paths + fallout.slnx paths
• namespace Nuke.X → namespace Fallout.X declarations
• using Nuke.X / qualified type references in .cs files
• InternalsVisibleTo attribute arguments (which take assembly names)
• Tool wrapper JSON + GlobalTool templates package refs
• Verify snapshot regeneration
• Carve-outs preserved as listed above

Deferred to follow-up (new issue, to be opened)

• Base class / interface renames: NukeBuild (96 uses) → FalloutBuild, INukeBuild (87 uses) → IFalloutBuild
• Internal identifier renames: NukeFileName, NukeDirectoryName, NukeCommonPackageId, NukeVersion, GetNukeDirectory, GlobalNukeDirectory, NukeTelemetryVersion
• Environment variable renames NUKE_* → FALLOUT_* (with deprecation fallback)
• Credential store name format "NUKE: ..." → "Fallout: ..." (with migration handling)
• Telemetry property keys version_nuke_* → version_fallout_*

Carve-out clarifications

• Constants.LegacyNukeDirectoryName = ".nuke" — kept as-is (explicit legacy reference to upstream NUKE convention)
• Constants.NukeCommonPackageId — identifier stays for now (deferred PR), but its value updates to "Fallout.Common" (the new package ID) in this PR. The nameof(Nuke) + "." + nameof(Common) expression on Constants.cs:29 won't compile after namespace rename — replacing with the string literal as part of the mechanical rename.