Evaluate a native Fallout.* compat-shim package

[ChrisonSimtian]

What

Decide whether to ship a compat-shim for native Fallout.* consumers, so the onion realignment (#359) is less disruptive for them.

Why

The realignment renamed namespaces, assemblies, and package IDs (ADR-0006). This breaks code using old Fallout.* names (e.g. using Fallout.Common;).

• NUKE consumers: covered by the Nuke.* shims.
• Native Fallout.* consumers: not covered. No Fallout.* -> Fallout.* bridge exists today. ADR-0006 deferred it on purpose.

Options

• Ship compat packages that reclaim the old IDs (Fallout.Common, Fallout.Build, ...) and re-export to the new ring locations, using the existing prefix-remappable shim generator.
• Or skip it and rely on fallout-migrate + docs.

Limits (a shim is not transparent)

• Same gaps as the Nuke.* shim (SHIM001): sealed types, structs, enums, attributes, and any API that returns new types into old-typed variables cannot be shimmed cleanly.
• [TypeForwardedTo] does not help across a namespace rename.
• Still a major release either way. A shim reduces blast radius; it does not remove the break.

Decision driver

How many real Fallout.* consumers exist today? The rebrand is new, so it may be near zero. Build the shim only if there is a cohort to protect.

Refs

• ADR-0006 (onion layering + namespace realignment)
• PR refactor(arch)!: onion layering + namespace realignment (ADR-0006) #359 (the realignment)