Streamable HTTP: close replayed request streams once no in-flight requests remain

When a client resumes a request stream with Last-Event-ID, the replayed stream stays open indefinitely (keep-alive now keeps it healthy) even when every correlated response has already been delivered or stored.

Three narrow races follow from this:

• A response that becomes store-visible while a resume is mid-flight is missed by that replay's snapshot and never delivered to the now-permanent successor.
• A superseded successor's dedup state does not transfer, so a double reconnect during an in-flight store write can double-deliver a response.
• A stream resumed after closeSSEStream polling delivers the replayed response but never ends.

Closing a replayed request stream after replay whenever no in-flight requests map to it turns the polling loop into one that converges: the client re-polls until a replay snapshot includes the response.

Applies to both main and v1.x (the send()/replay code has the same shape in both). Split out from the review discussion on #2547.

Start with the send()/replay code for Streamable HTTP in both the main and v1.x implementations, and trace how closeSSEStream polling handles resumed streams. Verify the three replay races and ensure a replayed request stream closes after replay when no in-flight requests map to it. Done means polling converges without missed or duplicate responses and the replayed stream ends.