afx Tower UI: gate-action button has multi-second latency on both click-response and action-reaches-builder

[amrmelsayed]

What's wrong

The gate-action button on builders in the afx Tower UI has noticeable latency in two places:

1. Click → UI response — after clicking the button, the UI takes a few seconds to respond (presumably during which a request is being made; no spinner / pending indicator visible).
2. Click → action reaches builder — even after the UI has responded, the actual effect (approval message reaching the builder, builder unpausing and observing the new porch state) takes a few additional seconds.

Total perceived latency: ~few seconds end-to-end for what feels like it should be sub-second.

Why it matters

• Multiple builders active in parallel sessions (today's session had 6 simultaneously at various gates). At ~3s per gate action, batched approvals add up.
• Without a pending-state indicator, the architect can't tell if the click registered. Risk of double-tap → double-approve attempts (which porch's idempotency may absorb, but the UX is bad).
• For high-throughput sessions (5+ approvals in a row), the cumulative wait becomes a real workflow friction.

Investigation pointers

• UI click → request: is the click handler doing any unnecessary work pre-fetch? Any animation that waits to complete before firing the request? Any debounce that's tuned too high for the use case?
• Request → backend: is the gate-action endpoint slow (DB write? File I/O? porch state synchronization)? Profile the actual round-trip.
• Backend → builder propagation: how does the builder learn about the gate state change? Polling (and at what interval)? Webhook / IPC? If polling, the interval may be the dominant latency.
• Tower message bus: afx send messages reach the builder via Tower; is the gate-state-change going through the same bus, and is there a queue depth issue?

Acceptance

• Click → UI response under ~500ms (or visible pending indicator if longer)
• Click → action reaches builder under ~1.5s end-to-end (or whatever's realistic without redesign)
• If sub-second isn't achievable without a significant redesign, document the inherent floor + add a pending indicator so the user knows the click registered

Workaround today

Use porch approve <id> <gate> --a-human-explicitly-approved-this directly from the architect's terminal — bypasses the UI entirely. But the UI exists for a reason; should work without the architect needing to know the CLI invocation.