fix: anchor exclude dirs to absolute paths so bandit honors --exclude

[elfensky]

Problem

collect_exclude_dirs() is documented as returning "All exclusion directories as absolute paths, for passing to external tools", but it returned str(scan_root / p) — relative whenever scan_root is relative.

The Python security detector derives scan_root from os.path.commonpath() of the discovered file list (scan_root_from_files), which yields Path(".") for any scan launched with a relative --path (the common case).

bandit is invoked with -r <absolute scan root> and matches --exclude entries against the absolute paths it walks. A relative entry like .worktrees therefore matched nothing, and bandit re-scanned excluded directories anyway.

Concrete impact

On a repo that uses git worktrees (.worktrees/ added to exclude), bandit re-scanned every worktree copy of the source tree, producing ~2000 phantom B101 "assert detected" findings from the duplicated test files — even though .worktrees was correctly excluded from every other detector (file count, duplication, smells, …). Security dropped from 100% to ~50% purely on noise.

Root cause

desloppify/base/discovery/source.py::collect_exclude_dirs joins exclusion names onto an unresolved, often-relative scan_root.

Only bandit surfaces this:

• file-discovery detectors (structural / smells / duplication) filter an already-relative file list via matches_exclusion's path-component match — they never hand a root to an external tool;
• ruff's --exclude tolerates relative entries;
• jscpd uses only Path(dirname).name;
• bandit receives a directory root and does its own recursive walk, so it relies entirely on --exclude — which was malformed.

Verified against bandit 1.9.4: an absolute --exclude /abs/.worktrees excludes correctly; a relative .worktrees does not.

Fix

Anchor a relative scan_root to its absolute form before joining the exclusion names — matching the .resolve() bandit already applies to its own scan target. Already-absolute roots are left byte-stable, so existing callers and the test_returns_absolute_paths expectation are unchanged. (7 lines.)

Testing

• New regression test TestCollectExcludeDirs::test_relative_scan_root_yields_absolute_paths — fails before, passes after.
• Existing TestCollectExcludeDirs, ruff/bandit exclude-flag, and bandit-adapter suites stay green.
• Full suite: 5810 passed, 6 skipped.
• End-to-end on the original repro: the security detector goes from 1961 phantom findings to clean (33 files scanned).

Follow-up (intentionally not in this PR)

The per-detector security cache (review_cache.detectors.security) is keyed by _file_fingerprint, which hashes the file set but not the exclusion config. So on an already-scanned project, changing exclude doesn't invalidate the cached security result until the file set changes (fresh scans are unaffected). A natural fix is to feed the active exclusions into the existing salt= parameter of _file_fingerprint — happy to send that as a separate PR if you'd like.

🤖 Generated with Claude Code