feat(agent): CVE suppression lifecycle — scheduled re-scan of .grype.yaml ignores

## Parent

Sub-issue of #104 (RFC: Automated toolchain version monitoring)
Related: #92 (container base image CVEs blocking pre-push)

## Summary

Add a scheduled GitHub Action that periodically re-scans suppressed CVEs in `.grype.yaml` to detect when `won't fix` vulnerabilities become fixable, then surfaces them as actionable items.

## Problem

When a CVE is marked `won't fix` by Debian, we suppress it in `.grype.yaml` to unblock developer workflow. But these suppressions are sticky — no mechanism exists to detect when:
- Debian publishes a security patch for a previously `won't fix` CVE
- A new CPython point release fixes a binary-level CVE
- A suppressed CVE's severity is upgraded (e.g., High → Critical)

Without automation, suppressions accumulate and become technical debt.

## Proposal

### Scheduled Action (weekly)

```yaml
# .github/workflows/cve-lifecycle.yml
on:
schedule:
- cron: '0 6 * * 1' # Monday 6am UTC
workflow_dispatch: {}
```

**Steps:**
1. Build agent Docker image (`docker build -t bgagent-local:latest agent/`)
2. Run grype *without* the ignore file: `grype bgagent-local:latest -o json`
3. For each CVE in `.grype.yaml` suppressions:
- Check if it now has a fix version available
- Check if severity has changed
4. If any suppressed CVE is now fixable:
- Open an issue (or comment on #92) listing the fixable suppressions
- Label with `security` and `good first issue`
5. If no changes: exit silently (no noise)

### `.grype.yaml` metadata format

```yaml
ignore:
- vulnerability: CVE-2026-5450
package:
name: libc6
reason: "Debian trixie won't fix — glibc upstream dispute. No exploit path in container context."
review-after: "2026-08-01"

- vulnerability: CVE-2025-69720
package:
name: ncurses-bin
reason: "won't fix in trixie. ncurses not used at runtime (build dep only)."
review-after: "2026-07-01"
```

The `review-after` field is advisory — the scheduled scan checks fixability regardless of date, but the date helps humans triage.

## Deliverables

- [ ] Create `.github/workflows/cve-lifecycle.yml` — weekly scan
- [ ] Define `.grype.yaml` metadata convention (`reason`, `review-after` fields)
- [ ] Script: compare current grype output against ignore list, detect newly-fixable CVEs
- [ ] Action output: opens/updates a tracking issue when suppressions become stale
- [ ] Document in AGENTS.md or CONTRIBUTING.md: how to add/remove suppressions

## Acceptance criteria

- Scheduled action runs weekly without failure
- When a previously `won't fix` CVE gets a Debian patch, the action opens an issue within 7 days
- Suppressions without `reason` fields are flagged as incomplete
- No false positives (doesn't open issues for still-unfixable CVEs)

## Out of scope

- Automatically applying fixes (that's a PR, not an Action)
- Scanning non-Docker dependencies (covered by Dependabot in #104)
- SLA enforcement on CVE fix timelines

Beginne mit den vorgeschlagenen Schritten in .github/workflows/cve-lifecycle.yml und prüfe die vorhandene .grype.yaml, den Docker-Build von agent/ und AGENTS.md oder CONTRIBUTING.md. Führe den aufgeführten grype-JSON-Scan gegen das erstellte Image aus und ermittle, wie Suppressions und ihre Metadaten verglichen werden. Als erledigt gilt die Aufgabe, wenn ein wöchentlicher Workflow neu behebbare oder unvollständige Suppressions erkennt, sie ohne False Positives meldet und stumm bleibt, wenn sich nichts geändert hat.

Vom Indexierungsmodell aus dem Issue-Text verfasst.