#361 Introduce `swampd`: long-running local daemon for shared cache, secrets, and extensions

Problem

Today every swamp invocation is a cold process: startup overhead is paid on every call, datastore reads go to the remote backend even when the same data was just fetched, and there is no shared local state across invocations or across machines. This shows up in three places that came up in community discussion:

1. Latency under fan-out. When an agent (or a parent agent spawning N subagents) calls swamp models in parallel — often the same model repeatedly — each invocation pays cold-start cost and round-trips to the datastore (e.g. S3, Aurora). There's no coordination layer to dedupe or warm-cache.

2. No centralized secrets / models / extensions. Working across a day-to-day swamp dir, a development harness as a parent dir for coding projects, and remote VMs means copying extensions, vault secrets, and data/context between folders and machines by hand. There's no single "source of truth" the local CLI can point at.

3. Datastores are remote-first. They're already a form of cache, but the hottest, most-recently-touched data still round-trips. A local tier in front of the remote datastore would absorb that traffic.

Proposed solution

Introduce swampd, a long-running local daemon (think dockerd / nix-daemon / emacs server) that the swamp CLI talks to over a local socket. Scope, at a high level:

• Tiered storage / hot cache. A local cache layer that sits in front of the configured datastore. Recently read/written model data is served locally; misses fall through to the remote datastore. Writes propagate.
• Centralized secrets, models, and extensions. A single host-level location that the daemon owns, so multiple swamp project dirs on the same machine share extensions and vault material instead of each project carrying its own copy. Remote VMs can be bootstrapped by pushing to the daemon rather than to a project dir.
• Fan-out coordination. Parallel invocations from the same host (subagents, workflows, scripted callers) hit the daemon, which can dedupe in-flight calls and share results. This is the natural home for the "offload short-term agent context to swamp" pattern.
• Execution dispatch. The existing local execution driver becomes one backend among several; the daemon can also dispatch to remote executors while keeping data centralized — the rsync-style execution driver hack that already exists in the wild is pointing at this shape.

Open design questions worth calling out:

• Optional vs always-on. Docker requires a daemon; nix does too. Should swamp require swampd, or auto-fork on first run (the opencode pattern dax described), or stay strictly optional with a fallback to the current in-process path?
• Single central daemon vs fleet. A single per-host daemon covers the cache use case cleanly. A coordinated fleet (host + remote) would cover Sergey's VM-push workflow. Both could be in scope; the first is the simpler starting point.
• Relationship to datastores. The daemon's cache layer should compose with any datastore backend (filesystem, S3, Postgres/Aurora) without the datastore knowing it exists.

Affected components

High level, the change touches:

• A new swampd binary (or swamp daemon subcommand) with lifecycle commands (start/stop/status) and an IPC surface.
• The CLI entry points to detect and prefer the daemon when present, with a clean fallback to today's in-process behavior.
• The datastore layer to slot a local cache tier in front of remote backends.
• Extension and vault resolution to consult the daemon's centralized host-level location before falling back to the project dir.
• The execution driver layer to allow the daemon to mediate fan-out.

Credit

This issue is filed at the request of community members in Discord. Design input from:

• webframp — articulated the fan-out / parallel-subagents use case, hot-local-cache framing, and the "single central swampd is enough to start, fleet later" position. Tested the Postgres datastore against Aurora Serverless.
• Sergey — articulated the centralized secrets / extensions / data story across three concrete use cases: day-to-day swamp dir with homelab context, dev harness as parent of coding projects, and remote VM bootstrapped from local state.