Adopt successor:"@next" on gitpush-core.sh's push-gate unlock, or keep the bare unlock - the FIFO queue is non-binding without it

ASK: should gpc_push_gate_release pass successor:"@next" on its unlock of <host>-host.push-gate, instead of the bare unlock it does today? WHY IT IS A DECISION AND NOT A CLEANUP, which is why it is not already done: gitpush-core.sh:557-602 carries a written refusal of exactly this change. The original blocker was MEASURED and is gone (OPS-257 / hub v2.59.20 made a grantee's extend read 'granted' rather than 'reacquired', so the 900s park cannot recur), but the paragraph then says adopting @next changes lane handoff for EVERY agent on EVERY push and routes the call to Elazar. I am not reversing a human-reserved disposition on a peer request. THREE NEW DATA POINTS, all from 2026-10-06 and none of them available when that paragraph was written: 1. coder-apiimages-cc measured 9 CONSECUTIVE acquire losses from the FIFO waiter HEAD position. lockNotifyWaiters() DMs every waiter 'call lock() now', so waiters are ranked by tool-call turnaround - i.e. by standing context size - and the hub's queue position therefore buys nothing. The largest-context agent can be starved indefinitely while ~29s holds cycle. This is the same shape as the seven losses recorded for 999f0ee. 2. coder-enamel-cc demonstrated the transfer is ALREADY reachable from a pusher without any script change: call lock() yourself first, run gitpush.sh (it detects the pre-held hold via GPC_GATE_PREHELD and declines to release), then unlock({successor:'@next'}). Done twice, handing the gate to coder-apiimages-cc. So this change removes a workaround; it does not unblock anything. 3. coder-apiimages-cc then measured the part that actually retires the old fear: with a HUB-GRANTED hold, gitpush.sh reported how_acquired=granted, ran normally, and the pusher's own later unlock answered not_held - i.e. the script's single unlock call site FIRES for a granted hold as well as a self-acquired one. The one call I would edit covers both paths and cannot strand a grantee. KNOWN RESIDUE the adopter must handle, unchanged: the grant copies the OUTGOING holder's note onto the successor's row (hub.mjs:9506, cur.note), so GET /locks shows the new holder carrying the previous agent's repo and branch until its first extend. Cosmetic in /locks, but it misreports who is pushing what. SCOPE IF GO: one line in gpc_push_gate_release, plus a fixture in gitpush-gate-test.sh forced red against the bare unlock - a transfer that has not been seen to fail is a green line, not a control. Must NOT fire on the GPC_GATE_PREHELD path, which already declines to release at all.