Bind HTTP request admission to transport EOF #195

Problem

The HTTP server recurrence services connections, receives bytes, and then services requests. A TCP EOF can therefore be discovered during receive after the connection-service phase has already checked Remoter.cutoff.

Today that newly observed EOF is not latched into the associated Requestant before request parsing. If the current response is persistent, response settlement can then create a fresh parser even though the peer has closed its sending direction. Any buffered suffix after the last complete request becomes eligible for admission as another HTTP request.

Why this matters

TCP EOF is directional: it should stop admission of new inbound HTTP requests without preventing the server from finishing the response for an already-admitted complete request. Failing to establish that boundary makes parser generations outlive the transport state that authorizes them.

Expected behavior

• Latch a newly observed transport EOF into the Requestant before servicing requests in the same recurrence.
• Do not admit an empty EOF to WSGI as a request.
• Allow an already-complete request buffered before EOF to finish normally.
• Never rearm a persistent request parser once the Requestant is closed, so a trailing buffered suffix is not admitted as another request.
• Preserve the server-to-client response direction until its own settlement policy closes it.

The regression should be covered with real client/server sockets and an actual client write half-close.

Upstream dependency

The behavior is generic HIO HTTP/TCP correctness, but the clean upstream port depends on the half-close foundation in #163 and the related parser-settlement prerequisite chain.