ci: gate on known advisories in the .NET dependency tree (RB-14)

npm audit --omit=dev gates the shipped frontend bundle; nothing equivalent
existed for the backend, so the entire .NET dependency tree — direct and
transitive — was unscanned (BIO-016 lists it first under "Absent").

The ticket's literal wording would not have worked. `dotnet list package
--vulnerable` is a reporting command: it prints the advisory table and exits
0 regardless. Verified with a throwaway project on System.Net.Http 4.3.0 —
severity High, GHSA-7jgj-8wvc-jh57, exit code 0. A bare `- run: dotnet list
package --vulnerable` would have added a line that reads like coverage in a
compliance review and enforces nothing, which is worse than leaving the gap
visible.

scripts/dotnet-audit.sh runs the scan and matches "has the following
vulnerable packages" — the exact sentence dotnet prints per project on a hit.
One script, two callers (ci.yml and ci-local.sh), so the workflow and the
local gate cannot drift apart.

No severity threshold and no suppression list: picking either before a real
advisory forces the question would be guessing at a policy nobody needs yet.
Secret scanning, BIO-016's other named absence, stays on the checklist.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.github/workflows/ci.yml

@@ -202,6 +202,11 @@ jobs:
       # run manually against backend/openzaak/ (see its README), never in CI.
       - run: dotnet test backend/BigRegister.slnx --filter "Category!=Integration"
         if: needs.changes.outputs.backend == 'true'
+      # RB-14/BIO-016: `npm audit --omit=dev` covers only the frontend; the .NET dependency
+      # tree was entirely unscanned. The script — not a bare `dotnet list` — is the gate,
+      # because `dotnet list package --vulnerable` exits 0 even on a High advisory.
+      - run: ./scripts/dotnet-audit.sh
+        if: needs.changes.outputs.backend == 'true'
 
   e2e:
     needs: changes