Normalise the package-id / project-name relationship so renames stop moving published ids #582

Problem

The dotnet tool's NuGet package id has changed three times in about a year. Two of those changes were published to nuget.org and had to be cleaned up by unlisting versions. There is no written rule for how a package id relates to the project and assembly that produce it. Each project rename has pulled the package id along with it.

What happened so far:

Cost so far: two unlisting sweeps, one draft migration guide written and then deleted, and a repo-wide docs sweep each time.

The onion-architecture migration (milestone #6) will rename many more projects. Without a rule, package ids keep moving with them.

Outcome

A written rule that separates two kinds of name:

• Internal names — project, assembly, namespace. Free to change as the architecture moves.
• Consumer contract — the NuGet package id. Does not change when a project is renamed.

Renaming a project stops being able to change what consumers install. When an id genuinely has to change, there is one documented process for it instead of an ad-hoc decision each time.

Acceptance criteria

• ADR records the rule: package id is a consumer contract, internal names are not.
• Every packable project sets PackageId explicitly, so it never defaults to the assembly name and never moves by accident.
• One document lists every published package id and the project that produces it.
• A build check fails when a packable project has no explicit PackageId, or when the set of ids does not match that list.
• The rule states the naming pattern new packages follow, so future ids are consistent from the start.
• The rule states that any future normalisation of existing ids happens once, at a yearly major cut, batched with other breaking changes, with a migration guide and a nuget.org deprecation. It does not happen incrementally.
• docs/agents/conventions.md links the rule.
• Fallout.GlobalTools 10.4.0-rc.4 is deprecated on nuget.org with Fallout.GlobalTool as the alternate package.

Notes

• Keep publishing the CLI as Fallout.GlobalTool #581 stops the current churn and reverts to Fallout.GlobalTool. This issue covers the durable rule, not that revert.
• Switch the global tool during migration, and target the kept package id #576 rewrites the tool pin in consumer .config/dotnet-tools.json files. Whatever id this issue settles on is the id that step must write.
• The decoupling itself is already in place and worth keeping: Fallout.Cli packs as Fallout.GlobalTool, and build/Build.cs now reads the id from the csproj rather than assuming it matches the project name.