Stack trunk is not migrated when the trunk branch's PR is squash-merged and the branch deleted

## Scenario

A stack whose trunk is itself a feature branch with its own PR to `main` (a common "stack on top of an in-review PR" setup):

```
main
└── feat/base → PR #1 (base: main) ← stack trunk, created with --base feat/base
└── feat/layer-2 → PR #2 (base: feat/base)
└── feat/layer-3 → PR #3 (base: feat/layer-2)
```

PR #1 is then **squash-merged** into `main` on GitHub and `feat/base` is **deleted**. GitHub automatically retargets PR #2's base to `main`.

## Observed

The stack's local metadata keeps `trunk: { branch: "feat/base", head: }` forever:

- `gh stack view --json` still reports the deleted branch as trunk.
- `sync` cannot fast-forward the trunk (its remote ref no longer exists), and nothing offers to migrate the stack onto `main`.
- Because the trunk commits were squashed, the layers also need a `rebase --onto` to shed the now-duplicated trunk commits — the merged-PR recovery that works so nicely for *stack members* doesn't cover the *trunk*.

## Expected

When the trunk's remote branch is gone and a merged PR from that branch into `X` exists, `sync` (or a dedicated command) should offer to migrate the stack trunk to `X` and cascade-rebase, mirroring the existing squash-merge recovery for in-stack branches. Even just a `gh stack init --retrunk ` escape hatch would help — today `init --adopt` refuses branches that already have PRs, so there is no supported path.

## Workaround that worked

1. `git branch -f feat/base origin/main` (keep the local trunk name, point it at main)
2. `gh stack rebase` (cascades cleanly; git skips the squashed patches)
3. Hand-edit the `gh-stack` JSON state file in `.git/` to set `trunk: { branch: "main", head: }`

After step 3, `sync` works normally again. Editing an internal state file obviously isn't a supported interface, hence this issue.

Version: gh-stack v0.0.8, gh 2.x, repo uses squash-merge as the default merge method.

Inizia riproducendo lo scenario di squash-merge con `sync`, quindi analizza come `sync`, `rebase` e `init --adopt` gestiscono le PR unite e il file di stato di gh-stack in `.git/`. Confronta la gestione di trunk con il recupero esistente dei branch nello stack; il lavoro è completato quando un trunk eliminato può essere migrato verso la destinazione della PR unita e i suoi layer possono essere sottoposti a rebase a cascata senza modificare manualmente lo stato.

Scritto dal modello di indicizzazione a partire dal testo della issue.