Add migration helper docs: alias nuke → fallout CLI per OS/shell #199

Context

Existing NUKE users have years of nuke muscle memory and nuke ... baked into scripts, READMEs, CI runbooks, IDE configs, and Stack Overflow answers. The Fallout global tool installs as fallout (src/Fallout.GlobalTool/Fallout.GlobalTool.csproj — <ToolCommandName>fallout</ToolCommandName>), so a fresh Fallout.GlobalTool install gives a fallout binary but no nuke on $PATH.

For migrating users, offer a low-friction bridge: keep typing nuke, have it run fallout. Pure docs page — no code — and a soft landing that pairs with Fallout.Migrate.

Done when

A new docs page (docs/migration/cli-alias.md, or a section in docs/migration/from-nuke.md) covers:

• PowerShell (Windows/macOS/Linux) — $PROFILE function: function nuke { fallout @args }
• bash / zsh — ~/.bashrc / ~/.zshrc alias: alias nuke='fallout' (note any -i interactivity caveats)
• fish — abbreviation: abbr -a nuke fallout (expands inline, friendlier than alias)
• Windows cmd / batch — doskey macro: doskey nuke=fallout $*, plus persisting via AutoRun registry or a startup script
• A "remove later" note — once scripts/runbooks are ported, drop the alias and the migration is complete

What to consider explicitly

• Don't suggest a symlink /usr/local/bin/nuke → fallout — a permanent system-level change with surprise potential. Per-user shell aliases are reversible and contained.
• Don't ship a nuke shim binary in Fallout.GlobalTool — prolongs namespace confusion and creates support burden. Alias-yourself keeps the migration boundary clear.
• Do link the alias guide from the README's "Migrating from NUKE" section and docs/migration/from-nuke.md.

Refs

• Companion issue: docs CLI cleanup (replacing stale nuke examples with fallout).