fix(auth): stop losing preserved plaintext, and claim the hand-off file atomically

Round 19 found real data loss rather than process noise, in two places.

**An unrelated settings edit destroyed the secret the durability gate had
just preserved.** The GET migration withholds its strip for a session-scoped
store, so `mcp.json` stays the durable copy — but the POST/PUT paths always
wrote the stripped shape. The GET also returns the rehydrated secret to the
settings form, which resends the whole object when the user changes anything,
so editing a timeout wrote the stripped entry, moved the only durable copy
into RAM, and lost it at exit. Every operation reported success. The client
config had the identical shape: the read-path guard was there, the write path
had none, and saving a CIMD URL did the same thing to the IdP client secret.

Both write paths now agree with their read paths: while the store cannot
outlive the process, the file stays the durable copy.

**The hand-off's delete is no longer a check-to-delete race.** Re-reading
immediately before `rm` caught writes that had already landed and was blind to
the one arriving between the check and the delete — destroying a *later*,
already-successful write, which is worse than the optimistic-write residual
and, unlike it, fixable without a lock. The file is claimed by an atomic
rename before anything reads it, so the migration operates on a snapshot
nobody else can reach and a writer that recreates `secrets.json` is simply
untouched.

Claiming introduced a failure mode the existing tests caught immediately: a
migration that aborts must not leave the secrets stranded at the staging path.
The snapshot is restored on any incomplete outcome, and when the live path has
been recreated in the meantime it is left in place with its location logged —
an operator-visible orphan is recoverable; clobbering someone's write is not.

Also:

- **`setMany`**, the write-side twin of `getMany`. `set` costs a whole-file
  read-decrypt-encrypt-write-verify cycle per call, and the settings form
  resends a server's full `env` map on any edit, so a 10-variable stdio server
  spent ~30 scrypt derivations saving an unrelated change. One cycle now; the
  keychain keeps its parallel individual writes.
- **A doc that contradicted its function.** `readOnDiskEncryption` still said
  it "never decrypts, so it needs no passphrase" — round 12 made it
  authenticate precisely because structure is not access.

Full `npm run ci` green, staged tree verified before running it.

Signed-off-by: cliffhall <cliff@futurescale.com>

core/auth/node/secret-store.ts

@@ -366,6 +366,21 @@ export interface SecretStore {
     requests: SecretBulkRequest[],
   ): Promise<Record<string, Record<string, string>>>;
   set(serverId: string, field: string, value: string): Promise<void>;
+  /**
+   * Write several of one server's fields in a single pass.
+   *
+   * The write-side twin of {@link getMany}, and the same shape of problem:
+   * `FileSecretStore.set` costs a whole-file read, decrypt, encrypt, write
+   * and verifying read *per call*, all serialized. A settings save resends
+   * the server's full `env` map even when the user edited something
+   * unrelated, so an entry with N secret fields paid roughly `3N` scrypt
+   * derivations on every debounced save — a stall that grows with the
+   * environment rather than with the edit.
+   *
+   * Optional: {@link secretStoreSetMany} falls back to parallel `set` calls,
+   * which is what the keychain wants (independent native round-trips).
+   */
+  setMany?(serverId: string, values: Record<string, string>): Promise<void>;
   /** No-op if no entry exists. */
   delete(serverId: string, field: string): Promise<void>;
   /** Remove every secret stored for this server id (called on DELETE /api/servers/:id). */
@@ -593,6 +608,26 @@ export async function secretStoreGetMany(
   return out;
 }
 
+/**
+ * Write several of one server's fields, using the store's bulk path when it
+ * has one. Falls back to parallel `set`s.
+ *
+ * The fallback keeps `set`'s contract: `Promise.all` surfaces the first
+ * rejection, which is what the routes translate into a 503.
+ */
+export async function secretStoreSetMany(
+  store: SecretStore,
+  serverId: string,
+  values: Record<string, string>,
+): Promise<void> {
+  if (store.setMany) return store.setMany(serverId, values);
+  await Promise.all(
+    Object.entries(values).map(([field, value]) =>
+      store.set(serverId, field, value),
+    ),
+  );
+}
+
 export async function secretStoreIsDurable(
   store: SecretStore,
 ): Promise<boolean> {