Design: server-side world persistence architecture

Decides where chunk/object content lives at rest and who may write it, now
that there are two server-side processes per world (the always-on FastAPI
backend and the per-join, reaper-killed Godot dedicated server).

Decisions: chunk data lives in the existing Postgres DB (not world.md's
per-world SQLite file); the FastAPI backend is the sole writer and the editor
saves to it over HTTP; the dedicated server pulls content read-only at startup
over a loopback /api/internal route with a per-spawn token; full-chunk PUT with
base_revision instead of JSON-Patch deltas; the client streams chunks over HTTP
through the existing ChunkStreamManager.set_server_rpc() seam.

Adds docs/architecture/world_persistence_impl.md and marks the superseded
sections of world.md (SS4, SS5) and editor.md (the request_chunk_edit path).
Design only -- no implementation code.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y2FESCaMXeJpC9gSctiEeD

docs/architecture/world.md

@@ -1,6 +1,10 @@
 # World Chunk Data Format & Persistence Architecture
 
-> **Status:** Proposed
+> **Status:** Proposed. The chunk format (§2, §3) is normative and implemented
+> on the client. **§4 (SQLite schema) and §5 (write ownership / write-behind)
+> are superseded by [`world_persistence_impl.md`](world_persistence_impl.md)**,
+> which stores chunks in the existing Postgres backend and makes the FastAPI
+> process — not the per-world Godot server — the sole writer.
 > **Owner:** Platform team
 > **Related:** Server authority + client prediction, avatar component system, content moderation & age verification, backend auth (JWT)