[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

```

该 issue 没有指出源文件或测试。首先跟踪服务器的 workspace 订阅路径和 relay 状态传输，然后使用所描述的大型和小型 workspace 进行复现，同时检查 socket 行为和日志记录。完成的标准是，具有大量历史记录的订阅保持连接，或者在未实现分页或 lazy loading 的情况下，明确记录该故障。

由索引模型根据 Issue 内容生成。