feat: add bandit action

[lhoupert]

Delegate bandit execution to lhoupert/bandit-action

Intent

Previously, the action ran bandit as a raw Python subprocess and parsed the JSON output itself.
This PR replaces that with a proper GitHub Action step — lhoupert/bandit-action — which runs
bandit and produces a SARIF file. The Python module then reads the SARIF output for reporting.

This is a cleaner separation of concerns: the action step handles execution (with GitHub's native
SARIF integration), and the Python layer handles aggregation and reporting only.

What changed

action.yml — adds a lhoupert/bandit-action step that runs before the Python module.
The bandit_scan_dirs and bandit_severity_threshold inputs are now passed directly to that
step instead of being forwarded to the Python code.

Why a fork? We pin to lhoupert/bandit-action@<sha> rather than the upstream
PyCQA/bandit-action because the upstream action pins its internal dependencies
(e.g. actions/setup-python@v6) to mutable version tags, breaking workflows that enforce
full SHA pinning for all transitive dependencies. The fork applies SHA pinning throughout.
See #6 .

runners.py — replaces run_bandit() (subprocess call → JSON parse) with
read_bandit_sarif() (reads the SARIF file left by bandit-action and normalises it into the
same internal dict shape).

settings.py — drops bandit_scan_dirs (no longer needed at the Python level), adds
bandit_sarif_path, normalises severity values to lowercase.

Tests — updated to cover the SARIF reading path; new bandit_clean.sarif and
bandit_issues.sarif fixtures replace the old JSON ones.

README.md — rewritten to explain the action's value over using bandit or pip-audit
directly, with a concrete PR comment example and blocking threshold reference tables.