Defensive cleanup in IIS request processing logic

[BrennanConroy]

While doing some random investigations and playing around with throwing from random places, I noticed that if

_bodyOutput.Complete();
_bodyInputPipe?.Reader.Complete();

// Allow writes to drain
if (_writeBodyTask != null)
{
    await _writeBodyTask;
}

// Cancel all remaining IO, there might be reads pending if not entire request body was sent by client
AsyncIO?.Complete();

if (_readBodyTask != null)
{
    await _readBodyTask;
}

was somehow skipped it could cause AVs. So adding a try {} finally {} to ensure that specific cleanup code isn't skipped.

[Copilot]

Pull request overview

This PR hardens IIS in-process request teardown by ensuring critical IO/pipeline completion logic runs even if an exception is thrown during late-stage request/response processing, reducing the risk of native callbacks interacting with already-collected managed state.

Changes:

• Wraps late-stage response completion / stream stopping / end-of-request production in a try/finally so the pipe/AsyncIO completion sequence always runs.
• Moves the “complete writer/reader + drain write/read tasks + AsyncIO.Complete” sequence into the finally block with additional explanatory comments.