`httpd.timeout` in CouchDB 3.2.0 `_changes` long-poll boundary

CouchDB 3.2.0 replaces the fixed 30‑second HTTP request limit with a configurable httpd.timeout integer in the httpd section of local.ini or default.ini. This timeout governs how long the server waits before returning HTTP 408 and aborting the connection. The same interval also governs _changes long‑poll feeds: if no change notification occurs within the configured period, the connection closes and the client must reconnect. Setting the value to 0 restores indefinite waiting, but the timeout applies uniformly across request and feed contexts.

The uniform timeout applies to both short‑lived API calls and indefinite _changes feeds, yet the documentation offers no per‑endpoint override or adaptive mechanism. Operators must choose between risking 408 errors for slow legitimate clients and retaining open connections under load, creating a configuration tension without granular control.

How does the timeout interact with multiple simultaneous _changes feeds on a single node? Can a client effectively extend the wait interval through request pipelining or intermediate proxies? What is the expected behavior when timeout is set to 0 alongside active long‑poll sessions that previously exceeded the default 30‑second bound?