[Bug]: Desktop server private memory climbs ~25-30 MB/h while idle (immortal Effect parent spans + always-on tracing)

[Benchance]

Before submitting

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

Area

apps/server

Steps to reproduce

1. Launch T3 Code desktop and leave a normal workspace open (window can be unfocused).
2. Confirm background profile is balanced (or custom with baseProfile: balanced) so provider health checks only run while foreground.
3. Do not interact with the Providers page; leave the app idle for several hours.
4. Sample the server child (…\T3 Code (Alpha).exe …\bin.mjs), not the renderer — prefer Private Bytes (Working Set can be trimmed by Windows and falsely drop).
5. Optionally inspect ~\.t3\userdata\logs\server.trace.ndjson for high-frequency spans parented by span IDs that never appear as ended "spanId" records.

Expected behavior

Idle server Private memory should be roughly flat. Background no-op polls should not retain unbounded tracing state. Startup spans for forever-running reactors should not stay open / pinned on long-lived fibers for the process lifetime.

Actual behavior

Server Private climbs steadily at ~25–30 MB/h with handle count flat. Growth continues for hours with zero provider health-check spans. Dominant idle work in traces is no-op PortDiscovery.pollTick (~3s), ServerSecretStore.get (~5s), and ws.rpc.server.reportClientActivity (~25s), mostly nested under parent spans that never end / remain pinned on parked fibers.

Impact

Major degradation or frequent failure

Version or commit

T3 Code (Alpha) desktop; server entry resources\app.asar\apps\server\dist\bin.mjs

Environment

Windows 11, desktop mode, local tracing writing ~\.t3\userdata\logs\server.trace.ndjson

Logs or stack traces

Hourly Private growth (same PID, no provider probes after ~16:15):

16:29  Priv=785.2MB  handles=283
17:30  Priv=799.9MB
18:30  Priv=827.3MB
19:30  Priv=865.7MB
20:30  Priv=893.9MB
21:30  Priv=933.3MB
22:30  Priv=960.3MB  (WS was OS-trimmed to 202MB; Private kept rising)
23:30  Priv=999.1MB

Slope ≈ +29–30 MB/h Private over the watch window.

Never-ended / immortal parent fanout in server.trace.ndjson:

~6900 kids  PortDiscovery.pollTick
~4100 kids  ServerSecretStore.get  (attributes include startup.phase=reactors.start)
~800 kids   ws.rpc.server.reportClientActivity

Workaround

Restart the desktop app / backend to reset Private. Setting provider health interval to 0 does not stop the idle climb once probes are already gated off.

Notes

Related but different: #3909 (Claude probe orphans), #2614 (orphaned t3 serve), #4773 (idle CPU), #5241 (opencode orphans). This report is in-process Private growth under Effect ParentSpan inheritance + always-on local tracing.