Python: a first-class fatal signal for function middleware (fail-closed escape from the auto-invoke loop)

[MohammadHaroonAbuomar]

Follow-up from #7515 (raised by Evan Mattson (@moonbox3) in review: #7515 (comment)).

_auto_invoke_function converts every function-middleware exception into a tool error and keeps looping (_tools.py), so the only loud escape from the loop today is MiddlewareTermination. Middleware that needs fail-closed semantics (enforcement layers, guardrails) must mutate shared state, raise the loop's one loud exception, and re-raise the real failure two hops away at the run boundary.

Proposal (either shape):

• a fatal flag on MiddlewareTermination that the loop re-raises instead of absorbing, or
• a dedicated MiddlewareFailure exception the loop propagates.

Either would give every function-middleware author fail-closed semantics without the state-mutation dance, and would let the agent-hooks feature (#7515) delete its halted-state back-channel and the approval-request special case.

Deliberately not included in #7515 since it widens the _tools loop contract.

[atty57]

I have this working locally: fatal=True on MiddlewareTermination, with the four seams that currently absorb a termination (agent + chat pipelines, _execute_single_function_call, and the harness loop's streaming consumption) re-raising when it's set. Default behavior unchanged, tests on the function seam and the agent pipeline, spec invariant table updated. Independent of #7515, it doesn't need to land first. MohammadHaroonAbuomar, since you filed this off your own PR, were you planning to take it? Happy to open the PR if not.
Two open questions for maintainers: flag vs. a separate MiddlewareFailure, and whether you want the agent/chat seams to honor it too or be function-only.