feat: analyze bundled permission grants

[chrisknvidia]

Part of #399

Depends on #404.

Scope

This draft is the BH3 follow-up for the remaining project-settings surface in issue #399:

• analyze exact project settings roots: .claude/settings.json and .claude/settings.local.json
• structurally classify permission-widening allow, additionalDirectories, and defaultMode declarations
• distinguish blocking critical grants from nonblocking, conditional, ignored, and restrictive settings
• preserve Claude Code trust, provenance, and interface qualifiers without claiming runtime activation
• merge BH1/BH2/BH3 into one terminal inspection result per physical settings document
• cover directory, ZIP, nested-ZIP, sanitized evidence, scoring, output formats, baselines, and incomplete/fatal behavior

Implementation status

The reviewed design and executable plan are committed. Production implementation is continuing through red-green slices.

Completed so far:

• frozen BH3 permission model and pinned 2.1.241 mode semantics
• full closed allow/ask/deny/additionalDirectories grammar and conservative precedence
• exact structural and matcher-work limits, including adversarial near-1 MB coverage
• pinned path normalization for POSIX, Windows drive/UNC, extended/device namespaces, and literal settings values
• fail-closed permission outcomes, exact domain-separated aggregate identity, safe BH3 finding construction, and constant hostile-input errors
• flat allowlisted evidence with literal/escaped Unicode, control, path, domain, MCP, and unpaired-surrogate non-disclosure coverage
• 593 focused analyzer tests plus Ruff, formatting, mypy, repeated specification review, randomized security review, and no open findings

In progress:

• parse-once exact settings-root integration and merged BH1/BH2/BH3 ledger ownership

Still pending:

• BH3 registration, provider-local structural retention, and strict blocking score floor
• graph/archive/output/baseline/CLI-exit integration coverage
• docs, corpus calibration, full scanner E2E, Docker, and practical pinned-runtime/config verification

Dependency and review

This branch starts from the current hardened draft PR #404 head. It targets main and must merge after #404.

This PR will remain draft while implementation, independent code review, regression testing, scanner E2E, corpus calibration, and practical runtime/config verification are completed.

[rng1995]

[SkillSpector Review]

This draft is not yet code-reviewable for its stated BH3 permission-grant scope. PR #429 and dependency PR #404 currently point to the identical head commit (8cf3376), so the displayed 18k-line diff is entirely inherited BH1/BH2 work and there are no BH3-specific production or test changes to evaluate.

Before requesting re-review, please:

1. Fast-forward/rebase this branch onto the final reviewed #404 head. #404 currently conflicts with main, so resolve that dependency conflict first and propagate the resolved head here.
2. Add the BH3 implementation and its focused positive, negative, boundary, archive, ledger, scoring, output-format, and baseline regressions described in this PR.
3. Isolate the stacked diff while #404 remains open—preferably by temporarily targeting #404's branch as this PR's base—so reviewers see only BH3 changes rather than re-reviewing the entire dependency.
4. Align the documented Claude Code semantics snapshot: this PR description names 2.1.241, while the inherited README/design currently state 2.1.238.

No inline findings are attached because this head contains no #429-specific code. Please keep the PR in draft and ping for re-review after the BH3 delta is present and the dependency/base conflicts are resolved.

[rng1995]

Reviewed this head against #404. It is the exact same commit (8cf33768) and contains no permission-grant/BH3 implementation to review; the PR description also says production implementation has not started and depends on #404. I left the hook-flow findings on #404 to avoid duplicate inline threads. Please add the #429-specific implementation (and return this to draft until then), then re-request review.

[rng1995]

Requesting changes because this PR is marked ready for review but has no #429-specific implementation: its head is byte-for-byte identical to #404, and the PR description says production implementation has not started. Please return it to draft, add the permission-grant/BH3 delta after its dependency lands, and then re-request review. The hook-flow implementation findings remain on #404 to avoid duplicate threads.