fix(derive): the profile config's password policy is the base again (M-2)

Python builds its PasswordGenerator with
`policy=self.config_manager.get_password_policy()` and merges an entry's own
`policy` block over that base per derivation. The port merged the entry block
over hardcoded defaults and never read the profile config at all, so every
entry in a profile with a non-default policy derived a *different password*
than Python. Nothing failed anywhere; it reached the user as a wrong password,
which is indistinguishable from data loss at the point of use.

materializeSecret now takes a `basePolicy` and merges the entry block over it.
All three callers supply the profile config's policy:

  - program.ts via basePolicyForOptions, resolved lazily so `entry list` and
    friends don't pay a second BIP-39 seed derivation for a policy they never
    use. `--vault` names an index file rather than a profile, so the config is
    looked for beside it and falls back to defaults when absent.
  - agent.ts from join(appDir, fingerprint), so a token-scoped reveal returns
    what the owner sees.
  - the TUI through a new sessionSecret helper that every menu path goes
    through, so a future call site cannot silently omit the base.

`util generate-password` is deliberately unchanged: it has no entry and no
profile, so its flags are the whole policy. It now says so in its own help
text rather than leaving the reader to infer it.

Evidence: js/packages/cli/test/passwordPolicy.test.ts covers config-only v2,
an entry overriding exactly one field, config-only v1 and exclude_ambiguous,
against values computed by the Python implementation — each also asserted
unequal to what the pre-fix code produced, so a regression fails loudly rather
than needing someone to notice a changed constant. Mutation-verified twice:
dropping basePolicy from the merge in secrets.ts, and making
basePolicyForOptions return {}, each turn all four red.

Found by the 2026-08-18 independent audit (js/SECURITY_AUDIT.md). The parity
fixture suite could not have caught this: those fixtures call generatePassword
with one already-resolved policy, so they prove the algorithm and say nothing
about where the policy came from.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01Vtx94nXDmNgXEeThUZP4QN

js/packages/cli/src/program.ts

@@ -151,7 +151,12 @@ function resolveHome(p: string): string {
   return p.startsWith("~") ? join(homedir(), p.slice(1)) : p;
 }
 import { AppDir, resolveAppDir, INDEX_FILENAME, BACKUP_EXTENSION, defaultBackupFilename } from "./appDir.js";
-import { loadConfig, saveConfig, mutateConfig } from "./configFile.js";
+import {
+  loadConfig,
+  saveConfig,
+  mutateConfig,
+  passwordPolicyFromConfig,
+} from "./configFile.js";
 import { AgentClient, AgentDaemon, agentSocketPath, DEFAULT_TTL_SECONDS } from "./agent.js";
 import { AuditLog } from "./audit.js";
 import { runTui } from "./tui/app.js";
@@ -235,6 +240,29 @@ async function openFromOptions(opts: GlobalOpts): Promise<OpenedVault> {
   return openVault(path, await resolveMnemonic(app, opts));
 }
 
+/**
+ * The profile config's password policy, which entry `policy` blocks override.
+ *
+ * Parity with Python, which constructs its PasswordGenerator with
+ * `policy=self.config_manager.get_password_policy()` and merges the entry's
+ * block over that base. Deriving from the built-in defaults instead produces
+ * a different password for every entry in a profile whose configured policy
+ * is not the default — indistinguishable from data loss at the point of use.
+ *
+ * `--vault` names an index file rather than a profile, so the config is
+ * looked for beside it; loadConfig returns defaults when none is there.
+ */
+async function basePolicyForOptions(
+  opts: GlobalOpts,
+  mnemonic: string,
+): Promise<PasswordPolicy> {
+  const app = new AppDir(resolveAppDir(opts.appDir));
+  const profileDir = opts.vault
+    ? dirname(resolveHome(opts.vault))
+    : app.profileDir(await currentFingerprint(app, opts));
+  return passwordPolicyFromConfig(await loadConfig(profileDir, mnemonic));
+}
+
 /**
  * Run a mutation under the vault lock, holding it for the whole
  * read-modify-write cycle.
@@ -351,11 +379,16 @@ async function openReadAccess(opts: GlobalOpts): Promise<ReadAccess> {
   const vault = await openFromOptions(opts);
   const localRows = async () =>
     Object.entries(vault.index.entries).map(([id, e]) => entryMetadata(id, e));
-  const localSecret = (id: string, timestamp?: number) => {
+  // Resolved on first use, not up front: reading the config costs another
+  // BIP-39 seed derivation, and `entry list` and friends never need a policy.
+  let basePolicy: PasswordPolicy | undefined;
+  const localSecret = async (id: string, timestamp?: number) => {
     const entry = vault.index.entries[id];
     if (!entry) throw new Error(`no entry ${id}`);
+    basePolicy ??= await basePolicyForOptions(opts, vault.mnemonic);
     return materializeSecret(vault.index, id, entry, vault.mnemonic, {
       ...(timestamp !== undefined && { timestamp }),
+      basePolicy,
     });
   };
   return {
@@ -367,7 +400,7 @@ async function openReadAccess(opts: GlobalOpts): Promise<ReadAccess> {
     },
     reveal: async (id, timestamp) => localSecret(id, timestamp),
     deliver: async (id, sink, command, timestamp) => {
-      const secret = localSecret(id, timestamp);
+      const secret = await localSecret(id, timestamp);
       const result =
         sink === "clipboard"
           ? await clipboardSink(secret.value)
@@ -1426,7 +1459,15 @@ export function buildProgram(io: ProgramIo = defaultIo): Command {
 
   util
     .command("generate-password")
-    .description("derive a password (Python parity: index 0, gen v1 by default)")
+    // Deliberately profile-less: this derives from SEEDPASS_MNEMONIC and the
+    // flags alone, never from a profile's configured policy. Unlike
+    // `entry reveal`, there is no entry and no profile to read a base policy
+    // from, so the flags ARE the policy — an unflagged run gives the built-in
+    // defaults, not whatever the active profile happens to be configured for.
+    .description(
+      "derive a password from the flags alone, ignoring any profile's " +
+        "configured policy (Python parity: index 0, gen v1 by default)",
+    )
     .option("--length <n>", "password length", "24")
     .option("--index <n>", "derivation index", "0")
     .option("--gen-version <v>", "generation version (1 or 2)", "1")