fix(persistence): write state.json and the search index atomically (#854)

[ydflow]

Closes #854.

Problem

saveState, saveStateForScope and the buildIndex save write in place (writeJson = open + truncate + write). A crash, kill, ENOSPC or power loss mid-write leaves truncated JSON, and the readers answer null for what they cannot parse — the loss is silent, which is what makes the state.json case dangerous:

• state.json — loadStateForScope falls back to StateSchema.parse({}): lastPullRev and every per-checkout pushBaseRevs entry are gone without a word, so the next push compares against a stale base. That is the stale-base overwrite class the worktree fixes (fix(push): stop offering a teammate's update back as a local edit (#823) #827, tracked in [bug] Follow-ups to the worktree fixes: import --from-mr never shares its learning, and push can still revert a teammate's update #823) closed.
• search-index.json — loadIndex returns null: recall silently loses the whole corpus until the next rebuild, and the shrink guard loses its baseline.

The repo already treats this exact failure mode as a bug: #831 made config.yaml saves atomic (Issue #823 item 14 — "a command reading it mid-save saw an empty file"), and saveUserVotes documents it for votes ("A torn plain overwrite would leave truncated YAML … silently wiping every doc's counts, all pending deltas, and the whole upvote ledger"). writeJsonAtomic (src/utils/fs.ts:161) already exists — temp file + rename, preserving the target's permission bits — these three writers just predate it.

Fix

Move the three writers to writeJsonAtomic:

• saveState / saveStateForScope (src/config.ts)
• the index save in buildIndex (src/utils/search-index.ts)

No reader changes; a successful write behaves as before, including file modes (existing files keep theirs; new state files get 0600, the same default writeJsonAtomic applies to the local-agent config today).

Tests

New src/__tests__/state-atomic-save.test.ts, mirroring the #831 method: intercept fse.writeFile to truncate the target, run a concurrent reader, then complete or fail the write with ENOSPC.

• saveState / saveStateForScope: the concurrent loadStateForScope sees the old complete state (lastPullRev intact, never parse({})), and a failed write leaves the previous state on disk.
• buildIndex: a concurrent loadIndex mid-rebuild sees the previous index, never null.

All 5 tests fail on main (the concurrent reader observes exactly the torn state: expected null to be 'abc1234', expected undefined to deeply equal ['a.md']) and pass on this branch. npx tsc --noEmit clean; npm run lint 0 warnings under --deny-warnings.

Real-CLI verification (607de7c)

npm run build, then node dist/index.js against a sandbox HOME and a local team-repo fixture with a learnings/ note — the writers behave end-to-end and leave no temp residue:

$ teamai pull
- [user] Pulling team repo...

state.json parses OK; lastPullRev = "73687bd"; workspaces = 6686d2852646
$ teamai recall "retry budget"
ℹ No matching learnings found for "retry budget".   ← relevance floor on a 1-entry corpus, as designed

search-index.json parses OK; entries = atomic-check.md
no tmp residue

The atomicity itself is what the unit tests above prove (a torn write cannot be reproduced in a passing CLI run by construction); this record shows the two writers work unchanged on the happy path.

[github-actions]

No findings.

The PR description includes sufficient testing for the runtime change, including a representative real-CLI verification. The record names commit 607de7c, which is older than the test-only head commits, but per the review rules this is non-blocking.