fix(auth): address Copilot review round 7 (five of six findings)

Five taken; one rejected with evidence, below.

- **The keychain hand-off ran outside the file lock.** Read → copy → delete
  has to be one transaction: another Inspector completing a `set` between
  the read and the delete had its brand-new secret removed without ever
  being copied — a write that reported success and then vanished, which is
  the loss the lock exists to prevent, reached through the migration meant
  to preserve things. The whole sequence now runs under the same
  cross-process lock every mutation takes.

- **An unmigratable entry was skipped and the file deleted anyway.** A key
  that is not `serverId:field` cannot be addressed through the store API,
  so it cannot be copied — which makes the hand-off incomplete by
  definition, and the complete-success rule then forbids removing the
  source. It was discarding that value permanently in order to tidy up a
  migration that had failed. The copyable entries still go across; the file
  stays, and says why.

- **`readOnDiskEncryption` accepted any format version.** A version-2 file
  was reported as a usable plaintext or encrypted store even though
  `readMap` refuses it and every save fails. Checked before the mode now,
  matching `readMap`.

- **The loose-mode warning at selection was encryption-blind**, claiming a
  reader could read the secrets of a file that is ciphertext, and it
  duplicated the caveat printed moments later by `warnAboutSecretStorage`.
  Selection now only repairs; the descriptor path does the reporting,
  because it is the one that knows whether the file is encrypted.

- **The footer's tooltip offered to copy the path without showing it.** The
  band stopped printing it and the accessible name carries it for
  screen-reader users, which left a sighted user unable to see where a
  custom destination points without pasting it somewhere else.

**Not taken: "`writeStoreFile` is not atomic."** It is. The finding reads
`store-io.ts` line 84 as a direct write, but `writeFile` there is imported
from the `atomically` package, not `node:fs`. Verified rather than argued:
writing over an existing file changes its inode (so a rename happened) and
leaves mode `0600`. I had started implementing the suggested temp+rename
before checking the import, which would have replaced a tested library with
a hand-rolled duplicate.

That check corrected something of mine, though: `tightenSecretFilePermissions`
justified itself with "a rename over a 0644 file keeps the loose mode
forever", which is false — the temp carries `mode: 0o600` and the rename
replaces the inode, so every *write* re-establishes it. The function is
still needed for the case it actually addresses: a file that exists and is
never written. Comment corrected to say so.

Full `npm run ci` green — 5,753 tests under the coverage gate.

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

core/auth/node/secret-store-selection.ts

@@ -49,6 +49,7 @@ import {
   secretStorageSummary,
 } from "../secret-storage-info.js";
 import {
+  acquireLock,
   FileSecretStore,
   readSecretFilePermissions,
   tightenSecretFilePermissions,
@@ -302,12 +303,12 @@ async function buildStore(
   // *verify* the result. The UI and the README both state the file is 0600,
   // so a file we could not tighten (owned by another user, on a read-only
   // mount) has to be reported rather than quietly described as protected.
-  const perms = await tightenSecretFilePermissions(filePath);
-  if (perms.state === "loose") {
-    console.warn(
-      `[mcp-inspector] The secrets file at ${filePath} is mode ${perms.mode.toString(8).padStart(4, "0")}, not 0600, and could not be tightened. Anyone who can read it can read the secrets in it.`,
-    );
-  }
+  // Repair only — the *reporting* belongs to the descriptor path, which
+  // knows whether the file is encrypted and so what the consequence
+  // actually is. This used to warn here too, in wording that claimed a
+  // reader could read the secrets even when the file was ciphertext, and
+  // duplicated the caveat `warnAboutSecretStorage` prints moments later.
+  await tightenSecretFilePermissions(filePath);
   return {
     store,
     info: await describeFileStore(store, filePath, kind, reason, detail),
@@ -479,6 +480,34 @@ export async function absorbFileSecretsIntoKeyring(
   if (!fsSync.existsSync(filePath)) return;
 
   const file = new FileSecretStore({ filePath });
+  // The whole read → copy → delete sequence runs under the same cross-process
+  // lock every mutation takes. Without it, another Inspector completing a
+  // `set` between our read and our delete has its brand-new secret removed
+  // and never copied — a write that reported success and then vanished,
+  // which is precisely the loss the lock exists to prevent, arrived at
+  // through the migration meant to preserve things.
+  let release: (() => Promise<void>) | undefined;
+  try {
+    release = await acquireLock(filePath);
+  } catch (err) {
+    console.warn(
+      `\n[mcp-inspector] Could not lock the secrets file at ${filePath} to move it into the OS keychain, so it has been left in place: ${err instanceof Error ? err.message : String(err)}`,
+    );
+    return;
+  }
+  try {
+    await handOffUnderLock(file, filePath, keyring);
+  } finally {
+    await release();
+  }
+}
+
+/** The hand-off body. Split out so the lock's release is unmissable. */
+async function handOffUnderLock(
+  file: FileSecretStore,
+  filePath: string,
+  keyring: SecretStore,
+): Promise<void> {
   let entries: Record<string, string> | null;
   try {
     entries = await file.readAll();
@@ -490,10 +519,19 @@ export async function absorbFileSecretsIntoKeyring(
   }
   if (!entries || Object.keys(entries).length === 0) return;
 
+  // A key that is not `serverId:field` cannot be addressed through the store
+  // API, so it cannot be copied — which makes the hand-off incomplete by
+  // definition, and an incomplete hand-off must not delete its source. It
+  // used to be skipped and the file removed anyway, discarding the value
+  // permanently to tidy up a file we had failed to fully migrate.
+  let complete = true;
   try {
     for (const [account, value] of Object.entries(entries)) {
       const parsed = parseAccount(account);
-      if (!parsed) continue;
+      if (!parsed) {
+        complete = false;
+        continue;
+      }
       // Strict: `get` answers `null` for an unreadable keychain as well as
       // for a missing entry, and this branch *writes* on `null`. A transient
       // read failure would therefore overwrite a newer keychain value with
@@ -516,6 +554,13 @@ export async function absorbFileSecretsIntoKeyring(
     return;
   }
 
+  if (!complete) {
+    console.warn(
+      `\n[mcp-inspector] Secrets from ${filePath} have been copied into the OS keychain, but at least one entry could not be read (its key is not in \`serverId:field\` form). The file has been left in place so nothing is lost.`,
+    );
+    return;
+  }
+
   try {
     await fs.rm(filePath, { force: true });
     console.warn(