Harden long-running servers and roll back secrets on failed saves - #763

What Changed

• SQLite: a statement prepare that fails is no longer cached. The Node SQLite client keeps a prepared statement for 10 minutes, but now caches a failure for zero time, so the next call prepares it again. GitManager's status cache already uses this pattern.
• Git: the polled status fetch now runs with -c maintenance.auto=false and --no-auto-gc, so it never starts git maintenance run --auto. The config setting also covers the submodule fetches it starts, which do not get the flag. Fetches and pulls the user starts are unchanged.
• Settings secrets: provider environment secrets and CLIProxyAPI hub secrets now share one set of secret store changes per settings update:
  • A changed key is stored before settings.json is written, and its previous value is recorded first.
  • If anything fails before the write completes (provider or hub persistence, normalization, or the write itself), the old values are put back and new keys are deleted.
  • Removed keys are deleted only after a successful write, and only when the written file no longer refers to them.
• Behaviour change: if deleting an unused provider key fails after a successful write, the update no longer fails. The failure is logged and the unused key stays, as hub keys already work. The two warning messages now say "settings secret" and log the key name, never the value.

Why

A server that runs for weeks hit three problems:

• SQLite: a prepare that failed for a passing reason kept failing for 10 minutes. Examples are a schema lock, or "no such table" while the separate CLI process is still migrating the shared database. Port of fix(sqlite): retry failed statement preparations pingdotgg/t3code#10584 (d06f0ff104).
• Git: every polled fetch ran gc --auto. When that gc fails, for example on a repository with missing objects, git retries it on the next poll and leaves a full-size tmp_pack_* behind each time. Port of fix(server): background git status fetches no longer fill the disk with failed repacks pingdotgg/t3code#13812 (95030dc674), plus the submodule case.
• Settings secrets: provider environment secrets were set or removed in the secret store before settings.json was written, and only hub secrets were restored when the write failed. A failed save could lose a removed API key, keep a replaced key that settings.json no longer matched, or leave a new key behind. A hub refused later in the same update also left the provider keys changed. Port of fix(server): restore secrets when settings persistence fails pingdotgg/t3code#12487 (6d68677ff9).

The WAL size cap and bounded event log records already match the reference. Replay-marker pruning does not apply, because Ryco's server stores no DPoP replay markers on disk.

Testing

• bun run check: formatting ok, 0 lint errors, typecheck:fast 12/12 ok
• RYCO_TEST_MAX_WORKERS=4 bun run --cwd apps/server test -- src/persistence/NodeSqliteClient.test.ts src/vcs/GitVcsDriverCore.test.ts src/serverSettings.test.ts: 3 files, 117 passed
• RYCO_TEST_MAX_WORKERS=4 bun run check:changed: typecheck ok, related ryco-cli tests ok, read-from-disk ryco-cli tests ok
• Each new test fails on the old code:
  • A query whose table is missing is prepared again once the table exists, on both the row path and the .values path.
  • The exact arguments of the status fetch are checked.
  • A real-git repository where gc --auto is due keeps its pack count after refreshStatusUpstream.
  • Two failed writes to an unwritable settings.json leave the secret store, the settings.json bytes and the loaded settings unchanged. The same edit succeeds once the directory is writable again.
  • A provider key change in the same update as a refused hub entry is rolled back.

Follow-ups

• Other fetches (branch picker, worktree prefetch) still allow gc --auto on purpose. They run when the user acts, not on a timer.
• The SQLite client used under Bun (@effect/sql-sqlite-bun) is upstream code. It does not cache failed statements, so it was not changed.

🤖 Generated with Claude Code

^{Need help on this PR? Tag @codesmith-bot with what you need.}