A phrase decision recomputes the typed graph inside the request

[WaylandYang]

From the review of #797, which is right to serialize materialization and does not cause this.

decide_alignment_phrase (review_routes.rs:1280) calls materialize inline, in the HTTP request. After #797 that call waits on a transaction-scoped advisory lock held for the whole recomputation of that base, and the wait has no bound — acquire_timeout covers checking out a connection, not waiting on a lock.

Measured on the branch:

• 500 statements: first run 4.2545363s, so a first bind on a large base is minutes of exclusive per-base lock.
• A waiting materializer pins a pool connection for the whole wait. Two waiters on a two-connection pool exhausted it: third acquire after 3.0063752s => pool timed out while waiting for an open connection.

The worker path is fine — align_phrases holds its own try-lock, so worker runs never queue. Review decisions have no such guard, so several people deciding phrases in one base queue on the lock, each holding one of 32 connections, each request hanging.

Two ways out, both leaning on machinery that already exists:

1. The handler enqueues rather than materializing, and the worker's end-of-run recheck picks up what arrived while it was running. That recheck is already in phrase_alignment, added in What a long document found #757 for this exact shape.
2. The handler takes pg_try_advisory_xact_lock and answers "already recomputing" when it cannot have it. Instant and honest, and again relies on the recheck.

Either way the person's decision is saved immediately; what moves is when the typed rows appear. Worth checking whether the review page reads them back straight after deciding, since that is what would make the difference visible.

Related: #798, the same shape for a kind-word decision waiting on the aligner.