docs(landing): correct the runbook against what the real run proved

[RonenMars]

The landing executed on 2026-08-01 as #497, #498 and #499.
All three slices merged with zero conflicts; the final tree comparison against the frozen prep snapshot came back with nine differing files, every one classified EXPECTED — no drift, nothing unexplained.
#457 is closed.

This turns the runbook from a plan into a record, and fixes the three claims the run disproved.
It targets land/integration-prep rather than main because that is where the live copy of the document is.

1. Guard B's enumeration must not be narrowed to $FORK..origin/main

This is the substantive one, and it is a latent safety defect rather than a stale number.

A companion document rewrote the guard's file enumeration as log --name-only $FORK..origin/main and expected it to reproduce the curated 21-file list.
It yields 8.
Seven of the eight hand-listed commits are ancestors of $FORK, so that range excludes them by construction.

The 15 files it drops include package.json, .github/workflows/test.yml, .github/workflows/deploy.yml and KICKOFF-landing-runbook.md — precisely the regressions fee27061 exists to undo and that slice A excludes by hand.
The guard meant to catch that class of mistake would have been blind to all of it.

The reason is structural and now stated in the document: prep's history is older than the fork, so a slice can revert main work that landed before the divergence point, not only after it.
Any enumeration bounded below by $FORK cannot see that class.
The curated list stays; the recipe is corrected.

Nothing slipped through on the real run, and that was checked rather than asserted: the wider 21-file guard was re-run retroactively across the whole landing, and every removed line is a genuine supersession (expo-mcp dropped by #489, test:e2e:mock rewritten by #470, the ship scripts moving their SENTRY_RELEASE exports, the Sentry investigation losing real org names by design, this document superseding its own text).
.github/workflows/deploy.yml, CLAUDE.md and docs/troubleshooting.md are additions only.

The CLAUDE.md case is written up with its mechanism: both slice B and slice C carried a copy predating #495, Guard B returned additions only on both (+16/−0 and +10/−0), and the reason is that git rebase applies patches rather than whole files, so non-overlapping hunks compose.
That was likely but never guaranteed — the guard is what turned it from an assumption into a fact.

2. #457 does not close itself

The old text said its diff shrinks as slices merge until it is empty and closes itself.
After all three slices merged it was still open, still reporting 73 changed files and +3446/−1126, while the tip-to-tip tree diff had drained to the nine EXPECTED files.

A PR's diff is computed against the merge-base, and every prep commit landed under a new SHA — slice A as a fresh cherry-pick, B and C as rebased replays — so nothing prep points at became reachable from main and the merge-base never moved.
Any PR whose content lands by replay rather than by merge must be closed by hand.

3. A --delete-branch needs its dependents enumerated first

New rule, stated generally: before deleting any branch on origin, list everything that depends on that ref — open PRs declaring it as their base branch included, not only things downstream of it in ancestry.

Ancestry-stacked is harmless; this run hit that case when land/slice-a was deleted before slice B needed it as a rebase base, and --onto origin/main $A_END is the same operation.

Base-ref-stacked is not.
GitHub closes such a PR automatically and the closure reads like ordinary cleanup.
The equivalent landing on the streamer repo hit this an hour earlier: the dependent PR was closed silently, its content dropped out of that landing, and the automation reported success.
The check is one gh pr list --json baseRefName command.

Also

• The version-conflict path is marked still unexercised. main was ahead at 188/40 during the real run, but no slice touches app.json or android/app/build.gradle, so no conflict arose. It was not exercised by the rehearsal either and must not be read as proven.
• The RNSentry note in the risks table is cleared — fix(ios): add RNSentry to the path-dependent Podfile.lock checksum list #495 closed that gap.
• The rehearsal notes are now committed in-repo, so the section points at docs/landing/ rather than a path outside the repo.

Deliberately not included

sessionNames.test.ts still needs adding to the load-sensitive suite list in docs/troubleshooting.md.
That file lives on main, so it wants its own one-line PR there rather than being bundled into a prep-targeted change.
It is recorded as outstanding in the document.