fix(auth): address Copilot review round 10, and document the concurrency design

The headline is a correction to my own claim rather than a new defect.

**The optimistic verify is weaker than the comment said it was.** It
described the residual as a crash between the write and the verifying read.
The reviewer pointed out that no crash is needed: order two writers as
write-A, verify-A, write-B, verify-B and both report success while A's entry
is gone — A's verify simply ran before there was anything to see, and B did
nothing wrong. A crash is one instance of that shape, not the whole of it.
The trace in the old comment quietly assumed A verifies *after* B writes,
which nothing guarantees.

Corrected in the doc comment, the README and the spec, and the honest
summary is now stated rather than implied: this converges in every
interleaving where the clobber lands before the verify, it is not mutual
exclusion, and a deployment that needs the guarantee wants an OS-backed lock
from a dedicated library — not another hand-rolled election. It remains
better than what it replaced, which lost updates across a wider set of
interleavings and could not be closed at all with what Node exposes.

The other findings:

- **An envelope naming the cipher still is not an openable one.** Round 9
  added a `kdf`/`data` presence check; three dot-separated strings satisfied
  it while an empty tag, a 4-byte IV or `N: 3` still made every decrypt
  throw — so the quiet "Encrypted file" footer went to a file whose next
  save was guaranteed to fail. Now validates part sizes, a non-empty
  ciphertext, and the scrypt cost parameters (node rejects a non-power-of-two
  `N` synchronously, out of the derivation rather than the decrypt). A
  positive control asserts a file we actually wrote still reads as encrypted.

- **`encryptionUnknown` + `looseMode` claimed an exposure it had not
  established.** With both set, `plaintext` is absent, so a `!== false` test
  landed on "anyone who can read it can read the secrets in it" — about a
  file that may well hold ciphertext we simply could not classify. Three-way
  now, in `secretStorageCaveat` and mirrored in the footer's tooltip, with a
  test on each.

- **The README described a lock that no longer exists**, which is the worst
  kind of stale doc: it stated a durability guarantee the code had stopped
  providing. Rewritten to describe the actual design, including the residual.

- **The private-method access in the concurrency test** now carries the
  justification the repo's TypeScript rules require: the asserted shape is
  `writeMap`'s real signature, so a rename breaks the line instead of
  silently detaching the stub, and a production injection seam would let the
  real write path drift from the tested one.

Also updates `specification/v2_servers_file.md`, which still described #1356's
world: one keychain-only store, and unavailability as a hard error. It now
covers store selection and the probe, the file format and lazy encryption
upgrade, the concurrency design and its residual, the `getStrict`/`getMany`
seams and the two traps `getStrict` hit, the durability gate on migration,
the keychain hand-off and its conditional delete, and how the active store is
surfaced.

Full `npm run ci` green. (One unrelated `AppRenderer` theme-flip test failed
once under full-suite parallelism and passes in isolation with and without
these changes — a flake, not a regression.)

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

clients/web/src/test/core/auth/secret-storage-info.test.ts

@@ -113,6 +113,27 @@ describe("secretStorageCaveat", () => {
     );
   });
 
+  it("does not claim exposure when the encryption state is unknown", () => {
+    // `looseMode` with `encryptionUnknown` leaves `plaintext` absent, and a
+    // `!== false` test then lands on the plaintext wording — asserting that
+    // a reader gets the secrets. The envelope may hold ciphertext; we could
+    // not classify it. Claiming the worse of two unknowns is still claiming
+    // something we never established.
+    const loose: SecretStorageInfo = {
+      kind: "file",
+      reason: "fallback",
+      durable: true,
+      looseMode: 0o644,
+      encryptionUnknown: "not valid JSON",
+      path: "/tmp/secrets.json",
+    };
+    const caveat = secretStorageCaveat(loose);
+    expect(secretStorageTone(loose)).toBe("warn");
+    expect(caveat).toContain("0644");
+    expect(caveat).toContain("could not determine");
+    expect(caveat).not.toContain("anyone who can read it can read the secrets");
+  });
+
   it("warns about a loose mode even on an encrypted file", () => {
     // The passphrase is then the only thing between a reader and the values,
     // which is worth saying rather than rendering the quiet neutral state.