fix(uploads): bound the silence in an upload body with a re-armed read deadline

A body that stopped arriving held one of the receive slots (#47) and a
spool file indefinitely. Every read of the upload body now pushes the
connection read deadline UploadIdleTimeout (default 60 s) ahead, so a
stalled body fails its read, Accept returns and the slot is released,
while a slow but moving body is never cut (ReadTimeout would cut it).

Two things found by running it over a socket:
- metrics.statusWriter had no Unwrap, so http.ResponseController could
  not reach the connection and the bound silently did not apply in the
  production handler stack. It now unwraps; a writer that still cannot
  set a deadline logs "upload idle bound unavailable".
- clearing the deadline on any read error left net/http's pre-reply
  drain of the unread remainder unbounded, so the connection hung. The
  deadline is now cleared only on a clean io.EOF.

ADR-033 limitation amended. A 1-byte-per-59-s drip is still unbounded.

Closes #56

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

DECISIONS.md

@@ -1461,10 +1461,16 @@ an hour of Swedish *was* an unknown here; it is now measured, see decision 8.)
    as busy beyond that. Together with the 20-job queue and the running job that bounds the spool
    at about (4 + 20 + 1) x 200 MiB = 5 GiB of the 6 Gi `emptyDir` (infra): raising any of those or
    `TAPIR_UPLOAD_MAX_BYTES` must revisit that sum (pinned by `TestNewIntake_Defaults...`, not
-   enforced against infra). **A slow-drip body holds its slot without a time bound**: the server
-   sets `ReadHeaderTimeout` only, because a `ReadTimeout` would cut legitimate 200 MiB uploads on
-   slow links; two slow bodies take a user's two slots and two such users make everyone's upload
-   busy. It needs a valid session; recorded as a limitation with a follow-up issue.
+   enforced against infra). **A body is bounded by its silence, not its length (#56, amended
+   2026-10-04)**: a `ReadTimeout` would cut legitimate 200 MiB uploads on slow links, so instead
+   every read of the upload body re-arms the connection's read deadline 60 s ahead
+   (`App.UploadIdleTimeout`). A body that stops delivering bytes fails its read, Accept returns
+   and the slot is released; one that keeps moving is never cut. The deadline is cleared only on
+   a clean end of body and stays armed after an error, because net/http drains an unread
+   remainder before replying. It needs `http.ResponseController` to reach the connection, so the
+   metrics middleware's writer implements `Unwrap`; where a deadline cannot be set the handler
+   logs `upload idle bound unavailable` rather than silently running unbounded. Still not
+   bounded: a body that drips one byte per 59 s holds its slot for as long as it keeps that up.
 
 8. **Chat reuses `chat.Service`; it is not forked.** The uploaded-transcript chat handlers
    look the row up through the RLS-scoped store, so a non-owner gets 404 by the same mechanism