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

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.

Start with the server entry at resources\app.asar\apps\server\dist\bin.mjs and reproduce the idle run while sampling Private Bytes. Inspect server.trace.ndjson for PortDiscovery.pollTick, ServerSecretStore.get, and ws.rpc.server.reportClientActivity spans whose parents never end. Done means idle server Private memory is roughly flat and long-lived reactor fibers no longer retain unbounded tracing state.