[Bug]: Large workspace causes permanent server reconnect loop when a remote client subscribes

The issue names no source files or tests. Start by tracing the server's workspace-subscription path and relay state transfer, then reproduce with the described large and small workspaces while checking socket behavior and logging. Done means large-history subscriptions remain connected, or the failure is recorded clearly if pagination or lazy loading is not implemented.

Platform

macOS

Operating system version

macOS Tahoe 26.5.2 (25F84)

System architecture

ARM64 (M1, M2, etc)

PolyScope Version

0.24.1

Bug description

On a Mac mini running as an always-on server, one specific workspace makes the
server's relay connection collapse into a permanent reconnect loop as soon as a
remote client subscribes to it. Other workspaces on the same server are fine.
It happens both from the desktop app and from the mobile web client.

The workspace that fails has a far larger history:

Workspace	messages	MB (messages.content)	sessions
workspace-a	15,363	40.3	40
workspace-b	262	0.6	3
workspace-c	0	–	0

workspace-a alone is 40.3 MB of a 48 MB polyscope.db, and 40.3 of the
41.1 MB of message content stored in the whole database.

It is not one oversized payload: the largest single message is 110 KB and the
mean is 2.7 KB. messages.metadata is negligible too (0.7 MB across the entire
database), so those figures account for essentially all of the stored state.
It looks like the cumulative volume pushed to the client on subscribe.

Nothing is logged on either machine. The only lines in main.log are
[updater] No update available.

Context: workspace-a had a long-running Autopilot goal going for two days.
When the Claude session limit is hit the SDK fires a burst of retries
(~23 messages), each opening a session — hence 40 sessions. So the history
inflates over time and the problem gets progressively worse.

Steps to reproduce

1. Have a server with one large-history workspace and one small one.
2. From a remote client on a different network (desktop app or mobile web), open
   the large workspace.
3. On the server, watch the outbound relay socket:
   lsof -nP -iTCP -sTCP:ESTABLISHED | grep -i polyscope | grep -v 127.0.0.1
4. Switch the client to the small workspace and watch again.

Observed

With a client subscribed to the large workspace, the server's relay socket never
survives ~5 s — new fd, new source port, new handle on every sample, with gaps
where no connection exists at all. Reconnect bursts fire three simultaneous SYNs
to the three getpolyscope.com Cloudflare addresses every 8–12 s.

tcpdump shows each attempt completing the TLS handshake, transferring roughly
50–85 KB, then closing — consistent with a state transfer that never finishes.

Switching the client to the small workspace stabilises the socket immediately:
same handle and source port held for minutes. Switching back breaks it again
within seconds. Reproduced several times in both directions.

Reproduced from the desktop app and from the mobile web client.

The server process itself is healthy throughout: 3 d 06 h uptime, no crash
reports, 1.1 GB of 24 GB RAM, zero swap.

Expected

A workspace with a long history should stay reachable remotely — ideally by
paginating or lazily loading history instead of pushing the whole thing on
subscribe. At minimum the failure should be logged instead of surfacing as an
intermittent "Disconnected" with nothing in main.log.

Ruled out

• Process health: uptime, memory and swap all normal (above).
• macOS App Nap and power management (pmset fully configured for always-on).
• Network topology / double NAT.
• Tailscale: identical behaviour with it disconnected, and tcpdump shows relay
  traffic leaving via the LAN address straight to Cloudflare, never via 100.x.
• Duplicated server identity: serverId and serverIdentity in
  ~/.polyscope/settings.json differ between the two machines.
• Oversized individual message or metadata: max 110 KB, mean 2.7 KB, metadata
  0.7 MB total.
• Client-specific issue: reproduced from two different clients.

Relevant log output