[Bug]: Pending user-input popup can never be dismissed after the provider session dies (e.g. server restart)

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web + apps/server

Summary

If the provider session for a thread dies while a request_user_input / AskUserQuestion popup is pending — e.g. the user restarts the server, or the provider process exits — the popup becomes permanently stuck:

• The message can't be submitted. Submitting appends a provider.user-input.respond.failed activity whose detail is "No active provider session is bound to this thread.", but the box stays open. Every submit just adds another failure.
• The popup can never be dismissed. The client only closes a pending user-input request on a user-input.resolved activity or when a failure detail matches the "stale pending request" pattern. That detail does not match, so the request stays open indefinitely.

Related but distinct issues: #4060 (desktop, stuck on user input GUI) and #5119 (Claude adapter leaking pending requests on teardown). This one is provider-agnostic and also triggers on a plain server restart.

Steps to reproduce

1. Have an agent call request_user_input so the question card renders in the composer.
2. Restart the T3 server (or let the provider process exit) while the card is pending — the thread session becomes stopped.
3. Type an answer and submit → error No active provider session is bound to this thread., and the card stays open.
4. The card can never be closed, and the thread stays unsettleable.

Expected behavior

Once the provider session is gone, the pending request is unanswerable and should be treated as terminal (like the existing Unknown pending user-input request stale path), so the popup closes and the thread can be settled or restarted.

Fix

PR https://github.com/pingdotgg/t3code/pull/5453 treats the "No active provider session is bound to this thread." respond-failure detail as a stale pending request in the matchers shared by the web, mobile, server decider, and projection pipeline.

Start by reviewing the shared pending user-input matchers used by the web, mobile, server decider, and projection pipeline, then compare the behavior described in PR #5453. Verify the server-restart reproduction and the relevant existing stale-request tests. Done means the pending popup closes after the provider session disappears and the thread can be settled or restarted.