bug: Workspace chat turns are hard-capped at 300s, ignoring the agent's configured execution timeout

[vybe]

Summary

A Workspace chat turn is hard-capped at 300 seconds and dies there. The cap is a module constant with no setting, no env var and no per-agent override — and it silently overrides the agent's own configured execution timeout, which defaults to 3600s and is operator-settable from 60–7200s.

Context

Reported from live use of /workspace: longer turns die after ~5 minutes and there is no way to regulate it.

src/backend/client_portal/service.py:

PORTAL_TURN_TIMEOUT_SECONDS = 300

That constant is passed verbatim as timeout_seconds= into run_resumable_turn for every Workspace turn. Meanwhile the platform already has a first-class per-agent bound — agent_ownership.execution_timeout_seconds (TIMEOUT-001, default 3600s, GET/PUT /api/agents/{name}/timeout, range 60–7200) — which the Workspace path never consults. So an operator who deliberately raised an agent's timeout to an hour still gets 5 minutes in the surface people actually work in, and nothing tells them why.

Two things to keep intact while changing the number, both load-bearing and both documented in that file:

• The derived bounds must move with it. PORTAL_ATTEMPT_CEILING_SECONDS = turn timeout + 10 (HTTP slack) + 300 (the Async chat_with_agent: long execution silently fails with null response (reader-thread) #678 reader-race auto-retry's second call), and PORTAL_MAX_TURN_SECONDS = 2 × attempt ceiling + 60 (a resume whose JSONL is gone re-runs the whole turn cold). PORTAL_INFLIGHT_TTL_SECONDS is sized off that. Raising the turn timeout without these moving reintroduces the feat(workspace): absorb the Session surface, with continuity parity (ent#358) #2120/bug(workspace): awaitPersistedReply can poll for an hour when the in-flight marker is orphaned #2133 failure: the in-flight marker expires while a live, already-billed turn is still running, and the client is told nothing is running.
• The frontend's own wait ceiling is derived from the same constants (REPLY_MAX_WAIT_MS_FALLBACK in src/frontend/src/components/portal/portalUtils.js), so the client must not keep waiting on a shorter or longer clock than the server enforces.

Raising the default alone is not the whole fix — an operator with a long-running agent needs the bound to follow that agent, and a client watching a 20-minute turn needs the surface to stay honest about it rather than presenting a dead spinner.

Acceptance Criteria

• The Workspace turn timeout is materially larger than 300s by default, and the value is justified in the code comment rather than picked arbitrarily
• The bound respects the agent's configured execution_timeout_seconds rather than a constant that silently overrides it (clamped to a sane Workspace ceiling if one is wanted)
• PORTAL_ATTEMPT_CEILING_SECONDS, PORTAL_MAX_TURN_SECONDS and PORTAL_INFLIGHT_TTL_SECONDS stay derived from the turn bound — no constant left sized against the old 300s
• The client's wait ceiling stays derived from the server's bound (no independent number to drift)
• A turn that legitimately runs past the old cap completes and renders instead of dying; the existing tests/unit/test_2133_* pins (or their successors) still hold against the real constants
• A turn that does hit the new bound fails with an honest, user-readable reason rather than a silent stop
• If the bound becomes configurable, it is surfaced where operators already set the agent timeout — not .env-only — with a named validation error on out-of-range input

Technical Notes

• Backend: src/backend/client_portal/service.py (PORTAL_TURN_TIMEOUT_SECONDS and the derived ceiling/marker constants; the run_resumable_turn call site), src/backend/services/session_turn_service.py
• Existing per-agent bound: agent_ownership.execution_timeout_seconds (TIMEOUT-001, feat: increase default chat execution timeout from 15m to 60m #665), GET/PUT /api/agents/{name}/timeout, and the bug/design: schedule vs agent timeout precedence is silent + SIGKILL error message is ambiguous #929 rule that a schedule's timeout_seconds may not exceed the agent cap — the same relationship applies here
• Frontend: src/frontend/src/components/portal/portalUtils.js (REPLY_MAX_WAIT_MS_FALLBACK, PORTAL_ATTEMPT_CEILING_S)
• Rooms share the surface — check whether the room turn path carries the same constant