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

## 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` — `fallout`), 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`).