[loveRhythm1990]

Concurrent journal users can exhaust the former five-second slot budget before they get a turn. Internal connection, visibility and I/O waits also need distinct settings rather than one timeout applied everywhere.

Use candidate defaults of 30s for the journal queue, 30s for backend connection/pool waits, 120s for backend read/write I/O, and 60s for write visibility. Keep admission/backend scheduling at 120s and SQLite busy waiting at 5s. The local smoke/benchmark clients retain a 1800s I/O window with a separate 30s connection/pool bound.

Add ADAPTER_REQUEST_TIMEOUT_SECONDS (default 1700s, maximum 1740s): a context-propagated cooperative budget shared by HTTP admission and the synchronous worker, journal waits, all chunks and backend calls. Each new phase uses the remaining budget. Expiry returns retryable 504, preserving the original request ID and durable recovery state.

This is deliberately not a strict HTTP wall-clock timeout. An in-flight synchronous I/O or commit must unwind safely; admission remains held until the worker completes. Input parsing/response serialization are outside this business budget. No thread, transaction or unknown write is forcibly abandoned. Longer queue waiting does not increase write throughput.

Validation: 429 tests passed with the evaluation extra installed; Ruff and whitespace checks passed. New tests cover shared/nested budgets, admission expiry while an original write retains its permit, journal waiting, multi-chunk expiry and idempotent recovery, separated HTTP timeouts, and expiry after a durable final commit. No remote deployment was changed. Candidate budgets still require mixed-load and multi-message validation after a reviewed image rollout.