Close the Gaps Left by Narrowing a Blocked Promotion to Develop #2614

Problem

#2549 (for #2534) moved the blocked-promotion check from the unattended-handoff picker to the worker. A round now narrows to develop instead of returning STOP. The local strict-review pass on #2549, run after it merged develop, found four gaps in that move. The maintainer chose to merge #2549 as it stood (#2556), so they are filed here instead of editing that pull request again.

1. A failed read reads as "not blocked". The picker's step "returns STOP where a read it needs cannot run" did not move with the check. Worker step 3 says nothing about a failed gh issue list --label decision read, so its "Where none does, continue to the promotion pull request" covers a failed read too. Under main or release the worker would then drive the blocked promotion and hand it to merge-and-release.
2. An answer that lands mid-run unblocks the promotion before the parked lane applies it. Parking step 2 says the decision issue closes once answered, and worker step 3 checks only open decision issues. Once the answer closes the issue, the next round's worker sees the promotion as unblocked and drives it. The blocked lane holding that answer is still untouched, since the picker never takes it and only an attended session hands it back. Where the park left no open thread for Merge Gate item 3 to stop on, such as the harness-refused-merge park, the promotion can merge before the answer is applied. The old picker STOP made this unreachable within one run.
3. Two sessions can edit one promotion body. A narrowed-round worker does a read-modify-write of the blocked promotion's body to add its Fixes line. An attended session may be working the parked lane at the same time, as picker step 2 itself allows. gh pr edit --body replaces the whole body, so one session's edit can silently drop the other's Fixes #N, and that issue then stays open after the promotion merges.
4. "Parks only on a choice the maintainer alone can make" leaves no route for an action only the maintainer can take. pr-review-conduct "Expected review loop" sends some actions, not choices, to the maintainer, for example a review stall with a human reviewer requested. "Only" bars parking on these, and STOP is for repository- or session-wide states, so the worker has neither. The step already names one non-choice park, the harness-refused merge, so the list is incomplete as written.

Done when

• Worker step 3 returns STOP or parks where the decision read cannot run.
• A run does not drive a promotion whose blocking decision was answered but whose parked lane has not yet applied the answer.
• The promotion-body update cannot silently drop another session's Fixes line.
• Worker step 5 names the non-choice maintainer actions that still park.
• Generated copies are rebuilt with build_dist.py.