Use idle read timeout for updates instead of total deadline

[mariusvniekerk]

Summary

• Fixes Update times out after 30 seconds #895: roborev update aborted with context deadline exceeded partway through downloading a release asset on slow connections.
• The update HTTP client used http.Client.Timeout = 30s, an overall deadline covering the entire request including the body download — a ~12MB asset can't finish within 30s on slow wifi even when data is flowing steadily.
• Replaced the overall timeout with a per-read idle timeout: a custom transport wraps each connection and refreshes the read deadline before every Read, so a transfer fails only when no data has arrived for 30s (a dropped connection). Slow-but-progressing downloads now succeed.
• Kept bounded setup timeouts (dialTimeout, TLSHandshakeTimeout) so unreachable hosts still fail fast.
• Added tests covering the no-overall-deadline guard, idle-timeout abort on a stalled connection, and success on a slow-but-steady trickle.

[roborev-ci]

roborev: Combined Review (109b7f6)

Summary verdict: One medium correctness risk remains in update metadata requests.

Medium

• internal/update/update.go:165 - Removing http.Client.Timeout makes update discovery unbounded because CheckForUpdate and its fallback still use context.Background(). Small metadata, checksum, or header responses can now keep roborev update or the TUI update check alive indefinitely if a server or proxy trickles bytes within the idle timeout, even though only large asset downloads need no total deadline.

  Fix: use a bounded context or a separate timeout-enabled client for check and fallback metadata requests, while keeping idle-only behavior for PerformUpdate asset downloads.

---

Panel: ci_default_security | Synthesis: codex, 7s | Members: codex_default (codex/default, done, 3m37s), codex_security (codex/security, done, 28s) | Total: 4m12s

[wesm]

oops I fixed this in a separate PR, is there more good stuff to include from here, worth rebasing?

[wesm]

looking

[wesm]

I think easiest to just close this, and if more issues come up we can address then