DECISION FOR ELAZAR: adopt unlock(successor:@next) for the push gate, or keep the plain release

NOT A DEFECT AND NOT BLOCKED ON CODE. This is a behaviour choice that changes lane handoff for EVERY agent on EVERY push, which is why it is filed as a decision rather than done. WHAT CHANGED. gitpush-core.sh carried an in-file refusal of unlock(successor:@next), and that refusal was MEASURED, not guessed: under the old hub a grant minted a lock row, a later POST /lock against any existing row came back reacquired:true, and OPS-210's do-not-release guard therefore made the grantee never release - the lane parked for the full 900s TTL. That is no longer true. OPS-257 (hub v2.59.20) mints reacquired ONLY when the hold opened as a plain acquire (hub.mjs:9460-9471); a grantee now reads how_acquired=granted, the guard does not fire, and the release happens normally. Re-verified in hub source 2026-09-18 and FORCED against the live venus hub in gitpush-gate-test.sh [12a/b/c] (granted -> PREHELD=0 -> release actually frees the lock). So the stated blocker is gone. The comment in gitpush-core.sh has been rewritten at the site to say so - keeping the measured history, marking it superseded, and explicitly NOT adopting. Shipped in c912031 under OPS-265. THE DECISION. With @next, an agent finishing a push hands the gate directly to the next waiter instead of releasing it into a free-for-all. Upside: no gap between release and the next acquire, so no third party can slip in ahead of a waiter that has been queued longest, and no waiter has to re-poll. Downside and the reason this is yours, not mine: it changes who holds the lane at the moment a push finishes, fleet-wide, and a grant PUSHES responsibility onto an agent that may be mid-compact, wedged, or about to be restarted - the current release makes the next holder ASK for it, which is self-limiting. A grant also only lands if the successor is on the roster AND already a registered waiter (hub.mjs:9597-9600); otherwise the hub refuses the grant and the unlock releases normally - so adoption degrades quietly to today's behaviour rather than failing loudly, which is comfortable but means a misconfiguration would be invisible. HUB CITATIONS (read-only; hub code is pm-llmmsgsrv-cc's lane, nothing to patch there): lockHowAcquired() hub.mjs:3072 (three-valued: acquired/stolen/granted); :9460-9471 reacquired minted in the /lock handler only; :9523-9531 how_acquired + reacquired on the response payload; :9597-9600 the three grant guards (no_waiters, successor_is_holder, successor_not_on_roster). NO ACTION UNTIL ELAZAR ANSWERS. Do not re-derive @next as unadoptable - that conclusion is spent.