Probable OOM with very large documents

Look at this fun spam:

```
Jul 16 10:41:04 godot-sync systemd[1]: backstitch-sync-server.service: Main process exited, code=exited, status=137/n/a
Jul 16 10:41:04 godot-sync systemd[1]: backstitch-sync-server.service: Failed with result 'exit-code'.
Jul 16 10:41:04 godot-sync systemd[1]: backstitch-sync-server.service: Consumed 1min 52.060s CPU time.
Jul 16 10:41:07 godot-sync systemd[1]: backstitch-sync-server.service: Scheduled restart job, restart counter is at 69.
Jul 16 10:41:07 godot-sync systemd[1]: Started backstitch-sync-server.service - Backstitch Sync Server.
Jul 16 10:41:07 godot-sync just[1680899]: mkdir: cannot create directory ‘/mnt/godot_sync_volume/automerge-server-data/prod’: File exists
Jul 16 10:41:08 godot-sync just[1680900]: warning: unused manifest key: profile.release_debug.default
Jul 16 10:41:08 godot-sync just[1680900]: warning: unused manifest key: profile.release_debug.panic-strategy
Jul 16 10:41:09 godot-sync just[1680900]: Finished `release` profile [optimized] target(s) in 1.64s
Jul 16 10:41:09 godot-sync just[1680900]: Running `target/release/server`
Jul 16 10:41:09 godot-sync just[1680900]: 2026-07-16T10:41:09.673300Z INFO server::tracing: Tracing subscriber initialized
Jul 16 10:41:09 godot-sync just[1680900]: started automerge sync server on localhost:8085
Jul 16 10:41:09 godot-sync just[1680900]: starting HTTP server on 0.0.0.0:3000
Jul 16 10:41:10 godot-sync just[1680900]: Client connected. IP: 144.xxxxx
Jul 16 10:41:10 godot-sync just[1680900]: Client connection completed successfully. IP: 144.xxxxx
Jul 16 10:41:10 godot-sync just[1680900]: Client connected. IP: 109.xxxxx
Jul 16 10:41:10 godot-sync just[1680900]: Client connection completed successfully. IP: 109.xxxxx
Jul 16 10:41:36 godot-sync just[1680898]: Killed
```

The same client(s) were connecting, then immediately the server is killed (probably because OOM). I imagine this is because samod needs to materialize a giant document and.... totally totally can't. This creates a horrible loop!

Start by reproducing the restart loop while connecting the reported very large document, then inspect the server's client-connection and samod document-materialization paths. Done means the server no longer reaches OOM and repeatedly restarts when handling that document, with a regression test or other demonstrated reproduction covering the case.

Written by the indexing model from the issue text.