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

### 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

```shell

```

Das Issue nennt keine Quelldateien oder Tests. Beginne damit, den Pfad des Servers für Workspace-Abonnements und die Übertragung des Relay-Zustands nachzuverfolgen, und reproduziere das Problem anschließend mit den beschriebenen großen und kleinen Workspaces, während du das Socket-Verhalten und die Protokollierung überprüfst. Als erledigt gilt die Aufgabe, wenn Abonnements mit großer Historie verbunden bleiben oder der Fehler eindeutig erfasst wird, falls Pagination oder Lazy Loading nicht implementiert ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.