A review click can wait on the aligner with no bound

[WaylandYang]

From the review of #792.

Deciding a kind word from the review page now writes the binding and its entity projection in one transaction, which is right: it is what stops an older agent run from applying its class after a person has decided. The transaction holds the type_bindings row from decide to commit, and inside it updates every entity in the base whose normalized specific_type matches that word. For a common word that is most of the base.

decide_alignment_kind_word is a synchronous HTTP handler, and the main pool sets no lock_timeout or statement_timeout — only query_engine/postgres.rs sets one, and that is for external databases. So a person's click can wait behind the aligner's entity update with no bound, and the only thing they see is a request that does not come back.

What it should do instead: set a lock_timeout on that handler's transaction and answer 409 when it expires, with a message saying the aligner is working on that word and to try again. A person who is told to wait a moment is in a different situation from a person watching a spinner.

Worth checking at the same time whether any other synchronous handler takes a lock that a background job can hold.

[rollroyces]

Picking this up. Two things to settle before I write the patch:

1. Scope of the fix. Is it a single-handler fix in `decide_and_apply` plus the 409 response, or a survey of every synchronous handler that holds a lock a background job can take? The issue body hints at the survey ("Worth checking at the same time whether any other synchronous handler takes a lock that a background job can hold"), but the explicit ask is the kind-word handler. My read: do the kind-word fix as a focused PR, list the other candidates the survey finds in the PR description, and let you pick which become follow-ups. That way the safety win is a small surface and the survey is documented even if the follow-ups are not in this cut.

2. The 409 message. You wrote "the aligner is working on that word and to try again." I'd word it as: `Retry-After: 5\n` + a body that names the binding (so the UI can show "this kind word is being aligned, retry in a few seconds"). The agent path is `align_phrases` which is queued, not locking the row, so the lock holder is something else — an older decision applying, a recalc, etc. Should the message say what kind of work is holding the lock, or is "try again" sufficient?

3. `lock_timeout` value. Postgres default is 0 (wait forever). 5 s feels right for an interactive handler — long enough that a one-off slow query doesn't 409 spuriously, short enough that a person's click is never waiting on an aligner. Reasonable, or is the project using a different value elsewhere I should match?

I'll wait on these three before writing code. The fix itself is small (~30-50 lines), the 409 contract is the part that touches the frontend and I would rather get it right first time.