Trust dialog suppressed by ancestor trust while permission loading exact-matches the workspace key — subfolder permissions silently dropped with no interactive remedy

Versions affected: introduced in 2.1.193; still present in 2.1.197 (latest) and 2.1.198 (next).

Repro

1. Trust a plain (non-git) parent directory by running claude there and accepting the trust dialog.
2. In a subfolder (non-git, or its own git root), add .claude/settings.json with permissions.allow entries.
3. Run claude in the subfolder → stderr shows "Ignoring N permissions.allow entries… this workspace has not been trusted" — and no trust dialog ever appears.

Root cause
Two trust checks disagree:

• checkHasTrustDialogAccepted (gates the TrustDialog at startup) walks up ancestor directories in ~/.claude.json projects — any trusted ancestor suppresses the dialog.
• isWorkspacePersistedTrusted (gates permission-rule loading) exact-matches the workspace key: gitRoot(cwd) ?? resolve(cwd) — no ancestor walk.

In the mismatch state, project permissions.allow rules and additionalDirectories are dropped, and the warning tells the user to "run Claude Code interactively here once and accept the trust dialog" — which the ancestor-walking check guarantees can never appear. Only subfolders outside the trusted parent's git repo are affected; same-repo subfolders resolve to the trusted git root and work correctly.

Impact
Reported by an enterprise customer (who independently root-caused it via strings on the binary). Managed fleets on ≥2.1.196 hit this on any non-git multi-project directory layout. The only remedy is a manual ~/.claude.json edit: projects["<exact path printed in the warning>"].hasTrustDialogAccepted: true.

Suggested direction
Align the dialog gate to the same exact-match workspace key so the dialog is shown in the subfolder. The reverse fix (honoring ancestor trust in permission loading) would weaken the trust model, so exact-match on both sides looks like the safe alignment.

Related: #72507, #72610 (same symptom family — trust dialog unreachable while permissions are gated — different triggers), #71562.