feat: limit concurrent chat agents with pooled admission - #27902

Add a two-pool concurrency cap for chatd agents, enforced when a worker
acquires chat ownership: at most 5 root chats and 10 subagent chats
generate concurrently on unlicensed deployments. Refused chats stay
running but unowned, stamped with capacity_queued_at for FIFO admission
and a queued banner in the UI. Deployments with remaining licensed
agent runtime hours are uncapped.

The admission policy lives in enterprise/coderd/x/chatd; OSS carries
only the AgentAdmission seam invoked inside the acquisition
transaction. Active use is counted from ownership plus fresh
chat_heartbeats, so slots self-free when a replica crashes or a chat
leaves running/interrupting. Interrupting chats bypass the cap so
over-cap users can stop their own chats.

Review feedback from cian: AgentAdmission and AgentCapacityPolicy always
shipped as the same object, so replace them with a single
AgentCapacityLimiter interface (Admit + Limits). Limits returns the caps
plus a capped bool instead of a Capped field. A noop limiter replaces
nil checks; chatd wires it whenever no factory is configured.

Consolidate CountChatCapacityActiveByPool and
CountChatCapacityUnownedByPool into CountChatCapacityByPool so admission
and the metrics loop share one scan, and widen idx_chats_capacity_active
to cover unowned chats so the merged query stays indexed.

…ents

Codex review findings on 546e293:
- An interrupting chat acquired by a replica that never refused it kept
  the queued banner because the clear only covered running acquisitions.
  Interrupting acquisitions now publish the clear too.
- A delayed queued capacity event could arrive after another replica's
  clear and restore the banner. Acquisition bumps updated_at while
  refusals do not, so the frontend merge now applies capacity events
  only when the snapshot is not older than the cache.

Also add the concurrent-agents docs section and point the queued
banner's learn-more links at it.

Codex found the cap can flip to uncapped (license update) between one
replica's refusal, which published queued=true, and another replica's
admission, which then read capped=false and skipped the clear, leaving
a stale banner. The clear condition now depends only on whether a real
limiter is configured: the noop limiter never refuses, so no queued
event can exist, while any real limiter may have refused while capped.
No dynamic state can desync the clear from the queued event anymore.

…pshot

Codex found the skipped-pool path published queued=true from a stale
candidate row: another replica can acquire the chat between the batch
query and the publish, and because the event payload reloaded the chat,
it carried the acquisition's new updated_at and defeated the frontend
freshness guard when delivered after the owner's clear.

enterCapacityQueue now validates and publishes from one snapshot: it
only queues chats that are still running, unarchived, and without a
live owner heartbeat, and the event payload is that same snapshot, so
a stale queued event either never publishes or carries pre-acquisition
updated_at that loses to the clear. Crashed-owner takeovers still queue
because their heartbeat is stale.

…kipped passes

Codex found prune starvation: with a sustained full-pool backlog every
acquisition pass ends on an all-skipped batch, which returned before
pruneCapacityQueue could run, so an entry for a chat another replica
acquired persisted indefinitely, suppressing the next episode's queued
event and measuring wait time from the previous episode.

An all-skipped pass now reconciles the local entries it did not see
with one targeted FilterChatCapacityWaiting query and drops those that
stopped being capacity-wait candidates. One bounded query per pass,
instead of paging the global candidate stream, which under churn had
no termination bound.

An all-skipped acquisition pass ended before reaching chats sorted
behind the known queue heads, so a chat arriving on a saturated pool
never got its queued event and open tabs kept showing plain running
state. Reconcile now lists all waiting chats once per all-skipped
pass, pruning departed entries and queueing arrivals in pools the
pass proved full.

…races

Two races found by review:

Resuming a chat from waiting or error during the runner's abandon gap
preserved worker_id/runner_id, so generation restarted on the retained
runner without capacity admission while the slot release may have
already admitted a queued chat. Idle-state resumes now clear ownership,
routing the resume through worker acquisition and re-admission.

A capacity clear published at acquisition could be rejected by the
frontend freshness guard when a newer status event advanced the cached
updated_at first, leaving the queued banner stuck on a generating chat.
Capacity events now order against a per-chat capacity revision (the
newest capacity event's updated_at) instead of the general guard.

…ity invalidation

The ordering guards can reject a legitimate capacity event when
delivery reorders against message sends that bump updated_at (for
example a queued event loaded before but delivered after a send to the
same still-unowned chat). The worker keeps its local queue entry and
emits no replacement event, so the banner would stay wrong until an
unrelated refetch. After merging a capacity event into the caches,
invalidate the chat entity when the merged result does not reflect the
event; the single-chat GET derives the authoritative queued state.