[Bug]: Settings → Archived doesn't list a thread archived after the page loaded, until the page is reloaded #28886

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

Steps to reproduce

1. Open Settings → Archived (a fresh page load). It lists 1048 threads, matching the database (archived_at IS NOT NULL AND deleted_at IS NULL = 1048).
2. Leave that page open and do not reload it.
3. Archive a thread from outside the page, for example by calling t3_thread_organize with action: "archive" (an agent archiving its own thread does exactly this). The database now has 1049.
4. Watch the open Archived page for longer than the query's 30 s stale time.

Expected behavior

The archived thread appears in the list (the list is newest-archived first, so at the top) without a reload. Or the list refreshes when a thread is archived while the page is mounted.

Actual behavior

The page still shows 1048 rows after 13 s and after 39 s. After a reload (Ctrl+R) it shows 1049 and includes the thread. The thread was never missing on the server: the database row and the server's archive query both include it.

A person hits this when a thread archives itself or is archived from another window: they open Archived to look for it, it is not there, and it looks lost until they reload.

Notes on the cause (read from main, not traced in the running build):

• archivedShellSnapshot is built with createEnvironmentRpcQueryAtomFamily in packages/client-runtime/src/state/orchestration.ts with no refreshTrigger, refreshIntervalMs or staleTimeMs, so it takes the defaults (30 s stale time, 5 min idle TTL in state/runtime.ts).
• ArchivedThreadsPanel.tsx only refreshes it after the user unarchives or deletes from that same page.
• Server side is correct: ProjectionStore selects archived rows with json_extract(payload_json, '$.archivedAt') IS NOT NULL, and this thread's payload has archivedAt set.

Impact

Cosmetic issue

Version or commit

server 0.1.7-nightly.20261101.4035

Environment

Server on Linux, web UI served by that server at 127.0.0.1:3773, opened in the T3 built-in Chromium browser. Thread archived through the agent t3_thread_organize (MCP) tool, not the UI.

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Reload the page (Ctrl+R). None applied in code. I can open a pull request for this once triage confirms the direction. Not written yet; I would measure two options: refresh the snapshot when a thread archive or unarchive event arrives, or give the snapshot a short refresh interval while the Archived page is mounted.

Limits of this report: reproduced in a background (not focused) browser tab, with the thread archived through the agent tool; I did not try archiving from another UI window or the mobile app.