fix(scan): honor .rafter.yml scan.exclude_paths on both engines (sable-yz0)

[Rome-1]

Summary

Customer planted fake Stripe keys in three scan.exclude_paths entries AND a non-excluded path → all three got flagged. exclude_paths was silently dropped. Fix the two root causes in v0.8.3:

1. BetterleaksScanner.scanDirectory() never received excludePaths — only the patterns engine got it, and auto (the default) picks betterleaks when the binary is on disk.
2. The patterns engine's walker only matched excludePaths entries against single directory NAMES (entry.name) — multi-segment paths like components/common/Mermaid.tsx and supabase/migrations/foo.sql got no filtering.

Solution: a single applyExcludePaths / _apply_exclude_paths chokepoint after both engines (and the --staged / --diff modes), with path-aware semantics:

Pattern form	Matches
scripts/ or scripts	the scripts dir at root + everything under it; also any segment named scripts anywhere (preserves the historical dir-name-anywhere behavior so existing node_modules policies still cover nested copies)
components/common/Mermaid.tsx	exact file at that relative path
**/*.sql (any glob char)	minimatch (Node) / fnmatch (Python), with auto-anchor for relative globs

Customer's exact repro

# .rafter.yml
scan:
  exclude_paths:
    - scripts/
    - components/common/Mermaid.tsx
    - supabase/migrations/20250215000000_resend_setup.sql

Plant a fake Stripe key in each excluded path + safe/leaky.ts. Run rafter secrets . on either engine. Before: all 4 flagged. After: only safe/leaky.ts. Verified locally on both --engine patterns and --engine auto (betterleaks).

Tests

Suite	Cases	Status
node/tests/scan-exclude-paths.test.ts (subprocess end-to-end)	5	Pass
python/tests/test_scan_exclude_paths.py (helpers + chokepoint + _scan_directory E2E)	12	Pass
python/tests/test_agent_scan_history.py + test_agent_baseline.py (regression)	23	Pass
node/tests/baseline.test.ts (regression)	12	Pass

Security review

rafter agent review — PASS for merge, no critical/high findings.

Two low-severity defense-in-depth observations tracked as the follow-up bead sable-aem (P3): cap pattern length at 512 chars in policy-loader to neutralize pathological minimatch/fnmatch input. Attacker model is local-only (need write access to .rafter.yml, at which point scanning is already neuterable), so impact is low and out of scope for this PR.

Two info-level notes:

• Dir-name-anywhere is broad by design. Bare entries like src or tmp drop findings under any matching segment in the tree — documented and intentional (back-compat with the historical RegexScanner walker). Worth surfacing in user-facing docs in a follow-up.
• Findings outside scanRoot keep the absolute path. Theoretical edge case — scanners produce in-root paths today; path.resolve canonicalizes .. before the prefix check, so traversal can't sneak under scanRoot.

Tracking

• Bead: sable-yz0 (P0 bug, claimed by me)
• Sibling beads from the same customer triage:
  • sable-s2t (P1) — PR-comment formatter shows hashed R-XXXXX rule IDs instead of scanner-native names
  • sable-5vo (P1) — verify remote scanner (rafter run / /api/static/scan) honors .rafter.yml scan.exclude_paths
• Follow-up from rafter review: sable-aem (P3) — pattern-length cap

What's still customer-blocking after this lands

• They need to upgrade past v0.7.9 (currently ~2 weeks behind master). Patching to v0.8.4 (which will include this fix) unblocks the local-scan case.
• The remote-scan case still isn't tested; sable-5vo covers the verification path. If rafter run doesn't honor .rafter.yml either, the fallback is rafter agent baseline and we'll document it.

🤖 Generated with Claude Code