Settle WSGI application and iterator exceptions truthfully #193

Problem

Responder.service() does not settle every WSGI producer failure consistently. Application invocation and iter() occur outside its exception boundary; a generic exception from next() is only logged; and an HTTPError raised after response headers have been committed is also only logged. These paths can leave the responder reusable or active after production has failed and can retain the application-returned iterable.

The response commitment boundary matters: an HTTPError raised before headers are sent can still be rendered as one valid finite HTTP response, but after commitment it cannot safely replace the partially queued response.

Expected behavior

• Catch failures from application invocation, iterator construction, and iterator advancement.
• Abort on generic failures, retaining the original cause and closing the application-returned iterable exactly once.
• Before commitment, close any application result and render HTTPError as a finite response.
• After commitment, abort on HTTPError without changing already queued bytes.
• Keep body and terminal-frame enqueue failures outside this issue.

Acceptance tests

Cover generic failures at all three producer boundaries, pre-commit HTTPError from the application and iterator, and post-commit HTTPError. Verify terminal state, first-cause retention, queued bytes, and iterable cleanup.

Dependency

The behavior is generally upstreamable, but its implementation depends on the responder abort semantics and PEP 3333 iterable ownership tracked by #191 and #192, plus their open prerequisites #179 and #181. A code PR should wait for that chain to land.