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>

clients/web/src/test/integration/auth/node/file-secret-store.test.ts

@@ -623,6 +623,22 @@ describe("readOnDiskEncryption", () => {
     ).toMatch(/unsupported envelope/);
   });
 
+  it("calls a newer format version unreadable rather than usable", async () => {
+    // `readMap` refuses such a file, so describing it as a working plaintext
+    // or encrypted store would present it as fine while every save fails.
+    await fs.writeFile(
+      filePath(),
+      JSON.stringify({ version: 2, encryption: "none", secrets: {} }),
+      "utf-8",
+    );
+    const store = new FileSecretStore({ filePath: filePath() });
+    const state = await store.readOnDiskEncryption();
+    expect(state.state).toBe("unreadable");
+    expect(state.state === "unreadable" ? state.detail : "").toMatch(
+      /format version 2/,
+    );
+  });
+
   it("needs no passphrase — it reads the envelope, never the payload", async () => {
     // A store whose key is wrong still has to be describable in the UI.
     const writer = new FileSecretStore({

clients/web/src/test/integration/auth/node/secret-store-selection.test.ts

@@ -704,22 +704,64 @@ describe("absorbFileSecretsIntoKeyring", () => {
     expect(warn).not.toHaveBeenCalled();
   });
 
-  it("skips an entry whose account key is malformed", async () => {
+  it("copies what it can but keeps the file when an entry is unmigratable", async () => {
     // A hand-edited file can carry a key that is not `serverId:field`. It
-    // cannot be addressed through the store API, so it is passed over rather
-    // than guessed at — but it must not abort the entries around it.
+    // cannot be addressed through the store API, so it cannot be copied —
+    // which makes the hand-off incomplete, and an incomplete hand-off must
+    // not delete its source. Removing the file anyway would discard that
+    // value permanently in order to tidy up a migration that had failed.
     const filePath = await seedFile({
       "no-separator": "orphan",
       "srv:oauthClientSecret": "from-file",
     });
     process.env.MCP_INSPECTOR_SECRET_FILE = filePath;
-    vi.spyOn(console, "warn").mockImplementation(() => {});
+    const warn = vi.spyOn(console, "warn").mockImplementation(() => {});
     const mod = await loadWithProbe(true);
     const keyring = new InMemorySecretStore();
 
     await mod.absorbFileSecretsIntoKeyring(keyring);
 
+    // The migratable entry is across...
     expect(await keyring.get("srv", "oauthClientSecret")).toBe("from-file");
+    // ...and the orphan still exists on disk rather than being dropped.
+    expect(existsSync(filePath)).toBe(true);
+    expect(JSON.parse(await fs.readFile(filePath, "utf-8"))).toMatchObject({
+      secrets: { "no-separator": "orphan" },
+    });
+    expect(warn).toHaveBeenCalledWith(
+      expect.stringContaining("left in place so nothing is lost"),
+    );
+  });
+
+  it("holds the file lock for the whole hand-off", async () => {
+    // Read → copy → delete must be one transaction. Another Inspector
+    // completing a `set` between the read and the delete would have its
+    // brand-new secret removed without ever being copied — a write that
+    // reported success and then vanished.
+    const filePath = await seedFile({ "srv:oauthClientSecret": "from-file" });
+    process.env.MCP_INSPECTOR_SECRET_FILE = filePath;
+    vi.spyOn(console, "warn").mockImplementation(() => {});
+    const mod = await loadWithProbe(true);
+
+    const { acquireLock } =
+      await import("@inspector/core/auth/node/file-secret-store.js");
+    // Hold the lock as the "other process" would.
+    const release = await acquireLock(filePath, { heartbeatMs: 20 });
+    let finished = false;
+    const handOff = mod
+      .absorbFileSecretsIntoKeyring(new InMemorySecretStore())
+      .then(() => {
+        finished = true;
+      });
+
+    await new Promise((r) => setTimeout(r, 120));
+    // Blocked on us, not steaming ahead and deleting the file.
+    expect(finished).toBe(false);
+    expect(existsSync(filePath)).toBe(true);
+
+    await release();
+    await handOff;
+    expect(finished).toBe(true);
   });
 
   it("runs the hand-off for an explicitly configured keyring too", async () => {