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

Closes #56

Co-authored-by: Mathias <mthbqv@gmail.com>

DECISIONS.md

@@ -1466,10 +1466,19 @@ 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 handler never clears the
+   deadline: an armed deadline also bounds net/http's drain of an unread remainder before it
+   replies, and net/http resets it itself before its background read. A deadline still armed
+   while the file is probed (the multipart part can end before the body's last bytes arrive)
+   costs at most keep-alive reuse of that connection, not the upload. The 60 s default is the
+   deployed value (cmd/tapir does not set it) and is pinned by a test. 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