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/client/node-persistence.ts

@@ -121,7 +121,18 @@ export async function writeClientConfigStore(
       SECRET_FIELD_IDP_CLIENT_SECRET,
     );
   }
-  await writeStoreFile(filePath, serializeStore(stripped));
+  // What actually goes to disk. The read-path migration already withholds
+  // the strip for a session-scoped store, but the *write* path did not — so
+  // saving any unrelated field (a CIMD URL, an issuer) round-tripped the
+  // rehydrated secret through the form and then wrote the stripped shape,
+  // moving the only durable copy into RAM to be lost at exit. The two paths
+  // have to agree: while the store cannot outlive the process, `client.json`
+  // stays the durable copy.
+  const durable = await secretStoreIsDurable(secretStore);
+  await writeStoreFile(
+    filePath,
+    serializeStore(durable ? stripped : validated),
+  );
 }
 
 /** Remove client.json and the install-level IdP secret from the keychain. */