REVIEWED_TREE: d4e2ff92e5297336d5c83747f27ee4f274b44ae6 /workspace/gstack

1. **A concurrent red backstop can erase an admitted repair.** `scripts/train-backstop.ts:214–228` reads the freeze without the land lock, then persists that snapshot. If land records its repair between those operations, `persist()` resolves the notes conflict with `ours`, replacing the new admission with `repair: null`. I reproduced this through `runBackstop()` and real notes pushes: origin held repair #7 immediately after admission and null after the backstop returned successfully. Another repair can then land before #7 is judged; a green backstop also lacks the admission needed to unfreeze. Severity: High; Blocks: yes

2. **Reverting to a previously covered tree leaves the queue permanently frozen.** `scripts/train-backstop.ts:170` invokes clearing only after an actual green gate, but the existing coverage return at lines 157–160 bypasses that gate. An admitted revert matching a retained green-train prefix returns `covered` forever, while its merged admission blocks another repair. I reproduced two consecutive callbacks with valid freeze/land evidence: both returned `covered`, dispatched zero gates, and left `cleared_at: null`. Active freezes must bypass coverage and obtain the required gate. Severity: High; Blocks: yes

3. **Legacy train freezes cannot use the promised direct-repair path.** `lib/ship-queue-land-direct.ts:42–45,216–217` admits these freezes, but admission runs only after acquiring the land lock. A partially published train retains a `phase: freeze` lock, and direct land has no authorized takeover for it. Reproduced with green pin checks: `--repair` returns `QUEUE_LAND_LOCKED`; adding `--break-lock` returns `QUEUE_TRAIN_FROZEN`. With trains disabled, the documented recovery remains impossible. Severity: Medium; Blocks: yes

Recommendation: request changes because a concurrent red backstop can erase repair admission and reopen the frozen queue before that repair is judged.
