Govern a base with one run at a time, so concurrent runs stop deciding the same cluster repeatedly

[WaylandYang]

Found while attributing the typed-graph bench's tokens (run on dev before #906). A third of one run's model tokens, about 5.3M of 16M, went to the governance agent, and not because there was that much to decide: 1346 review pairs received 8888 keep decisions, one pair ten decisions within 38 seconds from ten different runs. The duplicate-key errors on agent_decisions_open in the server log were the concurrent proposals colliding.

Cause. Every document's extraction enqueues a govern job for its base, and enqueue_unless_queued only skips a job that is still queued; with 64 workers each new job starts at once. Nine govern runs overlapped on one base, all read the same queue heads (the lock only marks stage = adjudicating, which the queue did not exclude), all asked the model about the same clusters, and close_review_auto's WHERE status = 'pending' let only the first close the row while every run recorded a decision.

Fix.

• govern() takes a per-base session-level advisory lock, try only, the way the vector index build does. A run that does not get it exits and enqueues one govern for a minute later (enqueue_unless_queued_after, deduplicated against queued jobs only, so the running job does not suppress it), which covers pairs that arrive after the running job read its last queue head.
• queue() and cluster_of() skip rows marked adjudicating.
• close_review_auto returns how many rows it closed; a keep or already-merged outcome records no decision when the row was already closed by someone else.

#906 switched governance off in the bench base, which hides this from the bench but not from a real base with a running agent.

Verified on a fresh database: new store test a_base_is_governed_by_one_run (second lock attempt fails until the first releases; another base is another lock), the server's governance and adjudication tests, workspace clippy.

🤖 Generated with Claude Code