Cleanup: delete dead memory-server + vestigial Arc<Mutex> wrapper in get_conn (post WAL-desync self-heal)

[onsails]

Two cleanup follow-ups split out of the WAL-desync self-healing work (master 8aecbab3; spec/plan under docs/superpowers/{specs,plans}/2026-06-14-wal-desync-self-healing*). Both are non-urgent and were intentionally kept out of that PR to keep its scope minimal.

1. Delete the dead stdio memory-server / HttpMemoryServer

crates/right/src/memory_server.rs (run_memory_server → MemoryServer holding a process-lifetime Arc<Mutex<Connection>>) is legacy and never launched in the current architecture:

• The generated mcp.json wires only the HTTP aggregator (generate_mcp_config_http; crates/right-codegen/src/pipeline.rs calls only that). The live agent config is {"right": {"type":"http","url":".../mcp"}} — no stdio entry.
• The aggregator dispatches through ToolDispatcher + RightBackend (aggregator.rs comment: "Replaces HttpMemoryServer").
• Its DB path is a host path the sandbox can't reach anyway.

It is harmless today but is a latent split-brain hazard if ever revived (it would hold a long-lived data.db handle across the WAL-desync recovery that deletes -tshm/-shm sidecars — exactly what we just removed from the aggregator). Action: remove the dead MemoryServer/run_memory_server/HttpMemoryServer code path and the MemoryServer CLI subcommand if nothing else depends on them. Verify no remaining references (codegen, main.rs subcommand, docs) before deleting.

2. Clean up the vestigial Arc<Mutex<Connection>> wrapper in RightBackend::get_conn

After dropping the connection cache (master 719bb360), crates/right/src/right_backend.rs::get_conn opens a fresh per-op connection but still returns Arc<tokio::sync::Mutex<right_db::Connection>>. With no cache, the Arc is never shared and the Mutex is never contended — both are dead weight (a heap alloc + a lock per tool call) and mislead readers into thinking sharing is intended.

Action: change get_conn to return right_db::Connection directly and update the call sites:

• ~18 sites in right_backend.rs currently do let conn_arc = self.get_conn(..).await?; let conn = conn_arc.lock().await; → collapse to let conn = self.get_conn(..).await?;.
• crates/right/src/internal_api.rs callers keep conn_arc alive across awaits — verify an owned Connection held across the await works (it should; just no .lock()), or keep a local binding.

Kept out of the original PR because it touches many call sites and is pure cleanup (no behavior change). The "Do NOT reintroduce a connection cache" doc comment on get_conn should be preserved.

Also noted (separate, lower priority)

Consider filing upstream against tursodatabase/turso#769: a stale -tshm authority + empty -wal slips past turso's authority-rebuild path into a hard "short read on WAL frame" instead of a rebuild. Our self-heal works around it; upstream is the real fix.