ci: add bandit security-scan job (Task A.2 from #158)

[BW-Projects]

Follow-up to the ruff CI PR (#160). Adds bandit as its own dedicated
CI job, separate from the ruff job — one tool per job, per the review
on #160, so a failure attributes immediately to the right tool.

Contributes to #158 (Task A — CI lint/format/security).

What this PR does

• Adds bandit[toml]>=1.9.0 to [dependency-groups] dev and a minimal
  [tool.bandit] block (exclude_dirs for build/venv/model dirs).
• Adds a bandit CI job, installed the same lightweight way as ruff
  (uv sync --locked --only-group dev --no-install-project — bandit
  scans source, the app runtime isn't needed).
• Annotates the four baseline findings with scoped # nosec comments +
  rationale on the offending lines (not a global skip list, so any new
  occurrence elsewhere is still flagged):
  • import subprocess (B404) — static argv, never a shell
  • subprocess.run(["xdg-open", …]) (B603, B607) — fixed argv, no
    shell, no user input
  • urllib.request.urlopen("https://huggingface.co", …) (B310) —
    hardcoded https URL, not user input
• Documents the local bandit command in CONTRIBUTING.md.

Why bandit alongside ruff's S rules

ruff's S category (flake8-bandit) already covers overlapping checks,
but bandit is the named scanner BSI compliance reports cite, produces
its own report format, and versions independently — so a dedicated,
clearly-labelled bandit job is worth the small overlap.

Maps to BSI IT-Grundschutz

• CON.8 §3.2.5 (Funktionstests und Sicherheitstests, automatisierte
  Codeanalyse) — bandit covers the named security-testing half.

Note

The grandfathered S607/B607 finding (xdg-open partial path) could
alternatively be fixed via shutil.which(...); deferred to a
follow-up with test coverage rather than changing behaviour here.

cc @gerardo-navarro

[JuergenFleiss]

looks good to me

Regarding the shutil.which alternative to xdg, we would have to check how this behaves in flatpak sandboxing.

[BW-Projects]

looks good to me

Regarding the shutil.which alternative to xdg, we would have to check how this behaves in flatpak sandboxing.

Yes, we can defer the change until you got the change to test + we setup a proper testing suite.