Adversarial suite: one pure gate function shared with merge-flow; name the remaining floor gaps (follow-up to #855) #860

Lane A follow-up to #855 (#707 adversarial suite).

1. One pure gate function. test/adversarial/adversarial.test.ts rebuilds mergeDecisionFor's inputs itself, so any input Lane A adds to the gate later won't reach the suite. The #855 reviewer measured these differences by reading merge-flow.ts:500-633:

• merge-in base;
• labels from issue.seen;
• money paths loaded from the remote ref;
• lockScopeOf fallback;
• outsidePlan;
• the post-decision holds.

Of these, money-path loading and the merge-in base are the ones that could give false comfort (inferred).

What must hold: the gate and the suite call one exported, pure function that takes the gathered inputs and returns the decision. I/O stays outside it. The suite's header claim "the same inputs" is then true by construction.

2. More floor gaps (measured by the #855 reviewer under a review.yaml that lists nothing). These merge in both scopes, and the suite's todo list doesn't name them:

• .worklane/config.yaml, .worklane/tests.yaml, .worklane/agents.yaml;
• .github/actions/**, .github/CODEOWNERS, .github/dependabot.yml.

Owner decision: should they join the floor (like C1 .claude/**)? At minimum, add a todo line for each now.

3. A3 half-check. The worker's claim reaches mergeDecision only as claim === 'protected', so the decision half of A3 can't fail by construction. Keep the class half (it caught the pr-rules mutant, 82 fails); drop or reword the decision half.

Protected where it touches src/merge-flow.ts or src/merge-policy*.ts: owner merges.