fix(ci): restrict Trivy to vulnerability scanner only

The first successful Trivy run (after #45 wired the manual install)
came back red on three "secret" findings, all of them demo RSA
private keys embedded in the README / test fixtures of a
cryptographic npm package, sitting deep in `.pnpm-store/v10/files/`
where pnpm content-addressably caches its packages. They are not
our secrets.

Two observations:

- The job already chains `gitleaks/gitleaks-action@v2` after Trivy
  — running two secret scanners over the same tree is just twice
  the false-positive surface.
- Trivy's own log helpfully suggests `--scanners vuln` when secret
  scanning is not the focus, and ADR-0015 always framed this step
  as "dependency vulnerability scan", singular.

Restrict Trivy to `--scanners vuln` so it only runs the vuln check
(against `pnpm-lock.yaml`, complementing `pnpm audit`'s npm-advisory
view with Trivy's broader source). Gitleaks remains the single
secret-scan source.

No `--skip-dirs` change needed: the vuln scan reads `pnpm-lock.yaml`,
not the unpacked store contents.

.gitea/workflows/ci.yml

@@ -101,8 +101,16 @@ jobs:
           tar -xzf /tmp/trivy.tar.gz -C /usr/local/bin trivy
           trivy --version
       - name: Run Trivy
+        # `--scanners vuln`: limit Trivy to vulnerability scanning. Its
+        # secret scanner false-positives on demo RSA keys embedded in
+        # the README/fixtures of cryptographic npm packages (which
+        # land under .pnpm-store/), and we already have gitleaks below
+        # as the dedicated secret-scan gate. Trivy's intent in this
+        # job, per ADR-0015, was always "dependency vulnerability
+        # scan" — restoring that scope.
         run: |
           trivy fs \
+            --scanners vuln \
             --ignore-unfixed \
             --skip-dirs node_modules \
             --exit-code 1 \