Epic: pluggable storage adapters for burn (server environments)

[willwashburn]

Why

Today every piece of session data burn captures lands in ~/.relayburn/ on the local filesystem: ledger.jsonl for turn records, content/{sessionId}.jsonl sidecars, ledger.idx / ledger.content.idx dedup hashes, an archive.sqlite read cache, and per-host JSON state (hwm.json, cursors.json, config.json, plans.json). The write path uses fs.appendFile with file-existence locks; the read path streams JSONL with no index.

That works for a single user on a laptop. It breaks when Claude Code or Codex runs in a server environment — ephemeral pods, CI runners, dev sandboxes — where the local filesystem disappears at the end of the run, and where the natural next step is to aggregate usage across many hosts into one durable store.

Goal

Introduce a StorageAdapter seam in @relayburn/ledger so the ledger/content/lock layers become interchangeable, and ship four adapters:

• file (default) — wraps the existing JSONL + sidecar implementation. Zero behavior change for current CLI users.
• sqlite — single-file DB. Replaces the JSONL+archive duo for users with a durable volume.
• postgres — server-shared. Multi-host aggregation is a first-class goal: N hosts ingesting the same Claude session converge to one canonical row each via content-addressed dedup keys (turnIdHash, etc.) declared as PRIMARY KEY.
• http — points at a new @relayburn/server package that holds one of the durable adapters internally.

Adapter selection is env-driven (RELAYBURN_STORAGE=file|sqlite|postgres|http).

Scope boundary: shared vs host-local state

Two classes of state, treated differently:

• Shared session data (turns, content, compactions, relationships, tool result events, user turns, stamps) → goes through the adapter, aggregates across hosts.
• Host-local state (cursors.json, hwm.json, config.json, plans.json, models.dev.json) → stays as filesystem JSON in RELAYBURN_HOME regardless of adapter. Cursors reference per-host inode/mtime offsets and are meaningless on another machine.

Non-goals

• Real-time push/replication between hosts (convergence happens via the shared store on write).
• Automated migration of existing ~/.relayburn data into a remote DB (a separate import/export tool can come later).
• Replacing the JSONL default for local CLI users.

Phases (sub-issues)

Each phase is independently shippable. Phase 1 is the prerequisite for everything else; phases 2–4 can be tackled in any order after that.

• storage: introduce StorageAdapter seam + FileAdapter refactor (Phase 1 of #139) #140 — Phase 1: StorageAdapter seam + FileAdapter refactor
• storage: SqliteAdapter (Phase 2 of #139) #141 — Phase 2: SqliteAdapter
• storage: PostgresAdapter with multi-writer aggregation (Phase 3 of #139) #142 — Phase 3: PostgresAdapter (multi-writer aggregation)
• storage: @relayburn/server package + HttpAdapter (Phase 4 of #139) #143 — Phase 4: @relayburn/server package + HttpAdapter