Move the constant values into Fallout.Core

[ChrisonSimtian]

First step of #584. Core is the innermost project, so it is where Fallout's own fixed values belong, and everything now reads them from there. Rebased on #581, so <PackageId> is settled.

The split

Constants.cs was two things in one file. Split on the line between data and behaviour:

Fallout.Core/Constants.cs	the ~32 const values — directory and file names, parameter names, env var keys, package ids, project URLs
Fallout.Build.Shared/FalloutPaths.cs	the ~19 helpers that derive a path or read the file system

Fallout.Build.Shared now references Core, so the values have one home and the helpers consume them from it.

Namespace

Constants sits in the root Fallout namespace, not Fallout.Common and not Fallout.Core. Core is the innermost ring and must not declare types under an outer layer's namespace — that inverts the onion in naming even when the reference direction is legal, which is exactly the case the existing dependency fitness tests cannot see.

Root Fallout costs nothing at the call sites: they all sit somewhere under Fallout, so unqualified Constants.X resolves by the normal enclosing-namespace walk. Only the using static form changed.

New spec Core_declares_no_type_in_an_outer_layer_namespace pins it. It caught a second, pre-existing offender on the first run: ExecutionStatus and ITargetModel, lifted into Core by the de-statification work, still live in Fallout.Common.Execution. Both are public, so correcting them is a breaking change and is batched to the yearly major per AGENTS rule #1. Fallout.Common.Execution is frozen in an explicit baseline the rule ratchets against — a list to shrink, never to grow.

netstandard2.0 on Core — the real reason

The first pass justified this with "Fallout.SourceGenerators and Fallout.MSBuildTasks consume these values". Both are wrong, and the comment on the csproj now says so correctly:

• No netstandard2.0 analyzer project reads a single constant. The generator used only the path helpers (GetDefaultParametersFile, TryGetRootDirectoryFrom), and those stayed behind in Fallout.Build.Shared.
• Fallout.MSBuildTasks never referenced Fallout.Build.Shared and reads no constant.

The actual forcing function is Fallout.Build.Shared itself: it multi-targets netstandard2.0, its own code (FalloutPaths, Notifications) reads these values, and it keeps that target only so the Roslyn generator can reference it. That matters because it is what makes the exit condition real — when #442 frees the SourceGenerators cone, Build.Shared drops netstandard2.0 and this target goes with it (#441).

netstandard2.1 is dropped, not added. Core has no conditional compilation and no 2.1-only API, so that asset was IL-identical to the netstandard2.0 one, and a 2.1 consumer resolves netstandard2.0 anyway. Core now targets netstandard2.0;net10.0 — one fewer target than before this PR.

What could not move

The path helpers (TryGetRootDirectoryFrom, GetFalloutDirectory, GetDefaultParametersFile, GetCredentialStoreName, …) need AbsolutePath, EnvironmentInfo and the file system. Core references nothing, so they stay in Fallout.Build.Shared. No constant was left behind.

Tool package id

Adds FalloutGlobalToolPackageId and uses it — UpdateNotificationAttribute previously printed the id as a literal. Still a hand-kept copy rather than a derivation: the attribute ships inside Fallout.Common and runs in a consumer's build, where no Fallout csproj exists to read <PackageId> from. Flowing it in at compile time is the follow-up on #584.

Still open from #584

• AC Enterprise hardening: repo nuget.config breaks corporate packageSourceMapping setups #2 — the duplicated values in the issue's table (fallback versions, nuget URLs, branch conventions) are untouched. This PR moves Constants.cs only.
• AC fix(nuget): repo nuget.config breaks corporate packageSourceMapping setups #5 — docs/agents/conventions.md does not yet say where a new setting goes.

Verification

• dotnet build fallout.slnx clean, 0 errors; Core emits net10.0 + netstandard2.0.
• Full suite green: 14/14 assemblies, 0 failures.
• The three CS1574 warnings from the first pass are gone — the <see cref="FalloutPaths"/> on Constants pointed at a type Core cannot see and fired once per target framework.
• Behaviour unchanged: every value and every helper body is identical to before.

🤖 Generated with Claude Code

[ChrisonSimtian]

we've been talking about it, now here it is: lets move all those hidden but very important (in the voice of donald trump) constants that define which versions and package ids to use into a more central place.
This will help moving forward if we ever want to change those (or even more importantly, if we HAVE to but we dont remember where they all were sitting...)