Global HTTP timeouts vs per-request context cancellation for long Git operations in Forgejo

I'm running a Forgejo instance (v1.21-era configuration) that regularly serves large repository pushes and LFS transfers, and I need to decide how to protect the server without breaking legitimate long-running operations.

From the documentation, the [server] section in app.ini exposes ReadTimeout, ReadHeaderTimeout, and WriteTimeout, enforced globally by Go's net/http server. Setting these aggressively guards against slowloris-style attacks and stuck connections, but my understanding is they would also abort slow but healthy pushes from clients on poor connections.

The alternative I've seen discussed is propagating the incoming HTTP request's context down to the spawned git subprocesses, so a client disconnect or deadline cancels the underlying command. My concern is that this appears not to be the current default behavior — the git process may keep running after the client goes away — and that adding it raises questions about orphaned processes and signal forwarding to process groups.

Which approach is more appropriate for a public-facing instance with frequent multi-GB pushes: tight global HTTP timeouts, or per-request context propagation to git commands? If I enable per-request cancellation, what guarantees exist that interrupted git processes are fully reaped rather than left as orphans? And is there a documented way to verify on a test instance which behavior my build actually exhibits?