Revisiting #940: narrow-scope file download from the web inspector

[kidproquo]

Hello,

I've prototyped a small feature on a fork and wanted to gauge interest before submitting a PR.

I've read #940 and fully understand the rabbit-hole concern (general HTTP serving, access controls, etc.). I'd like to ask whether a deliberately narrow version of this is something the project would consider, or whether the answer is still "no, use a real web server."

Disclosure: this was built with AI assistance (Claude Code). The code, tests, and docs are on the fork; I've reviewed and run them, but flagging it so reviewers can calibrate.

Fork branch: https://github.com/kidproquo/transmission/tree/feat/files-download-endpoint

What I built:

• GET /transmission/files/<id>/<file_index>[/<name>], streams a single file from a tracked torrent. 403 if the file isn't 100% complete. Range requests supported (single range, including suffix form).
• GET /transmission/files/<id>/zip?indices=..., streams a STORE-method ZIP of the listed indices, preserving the deepest shared folder. Uses libevent's chunked-reply API; ZIP64 fields are emitted when needed.
• Inspector file rows in the web client get a small download icon; folder rows hit the zip route when every contained file is complete.

Scope guardrails (compared to "general HTTP file server"):

• Only files the daemon already tracks, via id + index. No arbitrary path access; .. rejected before any lookup.
• Only complete files. Partial files return 403.
• Inherits the existing Basic auth, IP whitelist, host whitelist, and brute-force throttle. No new auth surface, no new config.
• GET only. No upload, no delete, no rename, no listing-by-prefix.
• STORE-only ZIP (no compression), streamed. No on-disk staging.
• About 250 LoC handler + 300 LoC ZIP writer + tests + docs. No new system dependencies.

I'm aware "make the daemon serve files" is a directional shift even at this scope, so I'd rather ask before opening a PR you'd have to close. Three plausible answers:

1. Position hasn't changed, please don't submit it.
2. Worth a discussion in PR form, let's see the diff.
3. Maybe, but only if scope X / Y / Z changes.

Happy with any of those. Thanks for your time.