What does this PR do?

Fixes the model_tools._run_async() running-loop branch so gateway/async callers reuse a persistent bridge event loop instead of creating and closing a fresh asyncio.run() loop per call.

The old running-loop branch created a disposable worker thread and event loop for every async-context tool call. Cached async clients such as AsyncOpenAI/httpx can outlive those short-lived loops, which creates stale-loop cleanup hazards and descriptor churn in long-lived gateway processes.

Fixes #16570.

Architectural note

This PR keeps the architectural direction aligned with the rest of model_tools._run_async(): main-thread and worker-thread paths already use persistent loops, and this change gives running-loop callers the same stable-loop behavior via asyncio.run_coroutine_threadsafe().

It also preserves the important timeout-cancellation behavior added by #17428. That PR fixed the "timed-out coroutine keeps running in a worker thread" bug, but kept the per-call worker-loop bridge. This PR keeps cancellation semantics while removing the per-call loop churn that #16570 reports.

e7feb84 independently attempted the same dedicated bridge-loop shape, which is useful signal that the architecture matches the issue. This implementation hardens that idea with locking, startup failure cleanup, explicit CLI/gateway shutdown, nested-call protection, health-checked bridge retirement, cancellation-safe one-off fallback, retired-loop closure, and regression coverage.

Related work checked

• [Bug]: Home Assistant tool still uses per-call asyncio.run() path inside running event loops #13586 / fix(tools): reuse persistent loop in Home Assistant async bridge #13422: Home Assistant-specific instance of the same persistent-loop pattern.
• fix(model_tools): cancel coroutine on timeout so worker thread exits + full traceback on tool failure #17428: merged timeout-cancellation fix for the existing per-call worker-loop branch.
• e7feb84: referenced from [Bug]: model_tools async bridge recreates loops in running-loop contexts #16570; same dedicated bridge-loop direction, but without the lifecycle and cancellation hardening in this PR.

Changes Made

• model_tools.py: add a dedicated persistent async bridge loop for callers already inside a running event loop.
• model_tools.py: add startup failure handling so a dead bridge thread is not published as usable state.
• model_tools.py: avoid self-deadlock when _run_async() is called from code already executing on the bridge loop by using a cancellation-safe one-off worker loop.
• model_tools.py: on timeout, cancel the scheduled bridge future and retire the shared bridge only if a health probe shows the bridge loop is stuck.
• model_tools.py: close retired bridge loops after their bridge thread exits, and keep normal shutdown from double-closing thread-owned loops.
• cli.py and gateway/run.py: call shutdown_async_bridge_loop() from existing cleanup paths after cached auxiliary clients are closed.
• Tests: cover bridge reuse, startup failure cleanup, timeout cancellation, nested bridge-loop calls, healthy in-flight work during another timeout, retired-loop closure, and CLI/gateway shutdown integration.

How to Test

uv run --frozen --extra dev python -m pytest -o addopts= --ignore=tests/integration --ignore=tests/e2e -m "not integration" tests/test_model_tools_async_bridge.py tests/test_model_tools.py tests/cli/test_session_boundary_hooks.py tests/gateway/test_gateway_shutdown.py -q
58 passed, 1 warning in 22.47s

python3 -m py_compile model_tools.py gateway/run.py tests/test_model_tools_async_bridge.py tests/gateway/test_gateway_shutdown.py tests/cli/test_session_boundary_hooks.py cli.py
exit 0; emits the existing cli.py SyntaxWarning about `return` in `finally`

git diff --check origin/main...HEAD
exit 0

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits
• I searched for existing PRs to make sure this isn't a duplicate
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes
• I've tested on my platform: macOS, Python 3.13.12

Documentation & Housekeeping

• I've updated relevant documentation -- N/A
• I've updated cli-config.yaml.example if I added/changed config keys -- N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows -- N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide
• I've updated tool descriptions/schemas if I changed tool behavior -- N/A