[Bug]: Stale link_request cards stay 'waiting' after the machine links, keeping a permanent 'Input' badge #28384

Before submitting

• I searched existing issues and did not find a duplicate. [Bug]: Linked environments says Create link is in Settings → Connections, but it's in Sharing & access #27688 and "Open question" banner opens an empty new thread when the child thread runs on a linked environment #27005 are related, since they are also about linked environments, but they are different bugs.
• I included enough detail to reproduce or investigate the problem.

Area

Linked environments (Labs): agent-requested link cards (link_request turn items) and the thread "Input" badge.

Steps to reproduce

1. In a thread on environment A (Linux server), have the agent call t3_environment_link for machine B several times with different clientRequestIds. In my case the first attempts failed: an address that was not http(s), then B unreachable.
2. While those cards are on screen, view the thread from a client whose active route lacks "Manage access". Each card then shows "Only a session that manages access here can answer this."
3. Switch the client to a route that has Manage access, and answer a later card, which links B successfully.
4. Have the agent call t3_environment_link again with the earlier cards' clientRequestIds and environmentId = B. Each call returns {"status":"linked"}.

Expected behavior

• When B gets linked, other cards that are still waiting and target the same machine are closed, or are marked "already linked".
• Repeating t3_environment_link with an already-linked environmentId and a waiting card's clientRequestId resolves that card.
• Any card still waiting is visible and answerable (decline / use existing) from a client that has Manage access.

Actual behavior

• Two earlier link_request items stay status = 'waiting' indefinitely, as read from orchestration_v2_projection_turn_items.
• The agent's re-calls return linked, but the items stay waiting.
• The cards do not render as answerable in the client, so the user has nothing to click.
• The thread keeps its "Input" badge in the sidebar. t3_pending_request list returns [], and the thread's pendingRequestCount is 0.
• The only way I found to clear them is closePendingLinkRequests, which runs when the thread is stopped or archived. Stopping a long-lived thread just to clear a badge is disruptive.

Impact

The "Input" badge stops meaning anything. The user keeps returning to a busy coordinator thread for no reason, and cannot tell when a real question is waiting.

Version or commit

Server 0.1.7-nightly.20261031.3991 (Linux x64). Windows desktop client of the same nightly.

Environment

• Environment A: Linux server.
• Client: T3 Code desktop on Windows, connected to A by a Tailscale route that lacks Manage access. It was later switched to an SSH route that has full permissions.
• Machine B: a second Linux server, linked from A over Tailscale Serve HTTPS.

Logs or stack traces

Read-only projection query, with ids shortened:

link_request  …link-ai-server-handoff-…-c   waiting   (posted 21:44Z)
link_request  …link-ai-server-handoff-…-d   waiting   (posted 21:45Z)
link_request  …link-ai-server-handoff-…-e   completed (the one that linked B)
t3_pending_request list -> {"requestIds":[]}

Workaround

Stop or archive the thread, which triggers closePendingLinkRequests. There is no way to close just the stale cards.

Possible fix

• When link_request.record links environment B, close the other waiting link requests on the same thread that target B.
• Make PeerLinkRequests.request with an already-linked environmentId resolve an existing waiting card that has the same clientRequestId.
• Leave waiting link cards out of the "Input" badge when the viewing client cannot answer them, or give agents a way to withdraw a card they posted.