perf(server): shell resume filters visibility once, not per thread

[tusharbhardwaj-bk]

Problem

When a client resumes its shell subscription (every reconnect, and every wake from sleep), the fork's currentShellExecutionStream in ws.ts did three things:

1. built the full unfiltered shell (all 196 active threads in prod);
2. read execution snapshots for all of them;
3. wrapped the frames in applyShellItemVisibility.

For a team-mode connection, and in prod every Clerk connection has an actor, step 3 ran getThreadShellById (5 statements) per frame, just to check owner/member. That's about 980 statements per resume, before the "synchronized" marker, even when the client missed no events.

Fix

Inside the existing T3-CUSTOM(expbkt3) block in ws.ts: the shell is filtered once with filterShellSnapshot(shell, actorUserId), the same owner/member rule the per-frame check applied to the same active-shell rows. Execution snapshots are then read only for visible threads, and the frames need no per-frame check. Unrestricted connections (actorUserId === null) are unchanged.

The live execution-frame path (wsVisibility.ts "execution" case) is deliberately left alone: the cheaper canAccessThread would also pass archived threads, which changes behaviour.

Evidence

Statements per shell resume on the prod copy (196 active threads). Prod users see 147, 32, 15, 15 and 1 of them.

	per-frame visibility	execution overlay	total
before	980	588	~1,576
this PR alone	0	3 × visible threads	~100–450
this PR + #227	0	3	~11

Tests:

• server.test.ts -t "subscribeShell|shell": 16 pass.
• wsVisibility.test.ts + accessRules.test.ts (the rule): 13 pass.
• vp run typecheck in apps/server is clean, and the fork-marker check passes.

Model/harness: Claude Opus 5.5 via Claude Code in T3 Code.

🤖 Generated with Claude Code