state: stop one cathode instance erasing another's

[tdwd]

The bug you saw

/title named a session and printed its confirmation, then the title never
appeared in ctrl+r — and some sessions were missing from the picker entirely.

Your live store had 47 rows and zero titles, and 7 cathode instances
running. That is the whole story: every state file is shared by every running
instance, and each one loaded the file at its own start. A write that rebuilt
the file from that in-memory snapshot erased everything the other instances had
written since.

A row is only ever written by the instance whose session it is, so the loser of
that race lost the row outright. Touch fires on every turn, so any other
window sending a prompt was enough. Store-only rows (a codex thread) vanished
from the picker; a claude session survived only because listClaudeSessions
re-reads the JSONLs from disk — which is exactly why this read as a display bug
rather than a data-loss one.

Reproduced before fixing:

a, b := openSessionStore(), openSessionStore()   // both start on an empty file
a.Touch("sess-a", ...); a.SetTitle("sess-a", "the one A named")
b.Touch("sess-b", ...)                           // B has never heard of sess-a
// → A's title = "", and sess-a is gone from the file

The fix

The file is the state; the in-memory map is a cache of it.

• A write is a read-modify-write under flock, never a dump of the cache.
  sessionStore.mutate is the only thing that writes the file.
• A read re-reads too, or the picker cannot list a session started in
  another window.
• flock rather than an O_EXCL lockfile, because the kernel releases it
  when the process dies. A lockfile left behind by a killed cathode would wedge
  every other instance, and breaking a stale one needs a timeout nobody can pick
  correctly. Windows has no flock, so it keeps today's behaviour behind a build
  tag — the far narrower race between the read and the rename.
• The temp file is uniquely named. Two instances sharing one
  sessions.jsonl.tmp wrote into the same file and renamed a half-finished one
  into place, which is the one way the whole store goes at once.

The same bug next door

Prompt history had it at the same frequency. Appends are O_APPEND and safe,
but maxHistoryEntries is 50, so an established history takes the cap-trim path
on nearly every turn — the whole-file rewrite was the write that actually ran,
and the append path was effectively dead. load now owns the cap rule for both
startup and append, and re-reads under the lock.

One deliberate behaviour change falls out: a prompt typed in another window is
now in this window's recall immediately, as it already was after a restart.

readJSONL/writeJSONL are shared (statefile.go), because the two stores had
each grown their own and only one of them had a unique temp name.

settings.go still has the shape and is recorded in CLAUDE.md rather than
fixed: saveSettings writes the whole struct with os.WriteFile, so a theme
change in one window reverts another window's diff-style change, and a crash
mid-write truncates the file. A read-modify-write cannot fix it alone — it
cannot tell a stale field from a deliberate one without the call sites saying
which field changed. Say if you want that next.

Tests

Four new tests, and each of the four mechanisms was confirmed load-bearing by
reverting it and watching the right test fail:

reverted	fails
re-read in mutate	TestAWriteKeepsWhatAnotherInstanceWrote
re-read in All()	TestThePickerSeesASessionAnotherInstanceStarted
the file lock	TestConcurrentWritesKeepEveryRow (5/5 runs)
re-read in history load	TestHistoryKeepsWhatAnotherInstanceAppended

go build, go vet and the suite are green, and the package builds and vets
clean for GOOS=windows and GOOS=linux as well.

What this does not do

The titles already lost are not recoverable — they were overwritten. And the
running instances keep their old image, so they will go on clobbering until they
are restarted.