fix(ci): accept the three new util-linux advisories alongside 53615 (#1156)

[VijitSingh97]

Closes #1156.

Build image (dashboard) fails the CVE gate on develop. The branch only looks green — its CI
has not run since 2026-08-19 17:58, before the advisories were published.

Reproduced directly rather than inferred from CI history: built the image and scanned it with the
gate's own flags.

BEFORE (develop as-is)                        exit=1    debian 13.6: 27 HIGH
AFTER  (the three IDs accepted)               exit=0    debian 13.6: 0

CVE-2026-53612, CVE-2026-53613 and CVE-2026-53614 are three more advisories in the util-linux family
that CVE-2026-53615 already represents — same affected packages, same fix, same clearing condition —
so they joined that entry instead of getting one of their own.

A base bump cannot clear them — checked, not assumed

build/dashboard/Dockerfile:7   FROM python:3.11-slim@sha256:9c900dea…
docker pull python:3.11-slim   -> sha256:9c900dea…            (the SAME digest)
dpkg-query -W util-linux       -> 2.41-5                      (advisories name 2.41.5-0+deb13u1)

The digest we pin already is the newest published one. Dependabot has nothing to offer here and
neither does a manual bump; this closes only when upstream rebuilds the image on the fixed Debian
packages. docker run --rm python:3.11-slim dpkg-query -W util-linux is the one-line check, and all
four IDs go together.

One thing I could not fully explain

The same job passed on develop-v2's push run at 13:55 today, ~20 minutes after failing on two
PRs at 13:32 — and my own scan at ~14:30 reproduces the failure. So the check is currently
non-deterministic between runs, not simply red.

I did not establish the cause. The likely one is the trivy-action's vulnerability-DB cache serving a
snapshot that predates the advisories to some runs and not others — that is a hypothesis, not a
finding. Worth knowing either way, because a check that flaps is worse than one that is honestly
red: it is how a scan gate quietly stops meaning anything. Flagged on the issue rather than guessed
at here.

This change makes the outcome deterministic in the safe direction — accepted findings do not depend
on which DB snapshot a runner happens to hold.

Scope

develop, because .trivyignore is shared by both lanes and changes flow develop → develop-v2.
The next twin sync carries it. develop-v2 currently has the same three advisories unaccepted; its
own push runs have been passing, which is exactly the non-determinism above.

Not done

• No new tier-1 test. The scan is the behavioural gate, and an assertion that a file contains a CVE
  id would be a source-text check of the kind this repo keeps finding cannot fail.
• The flapping itself is not fixed — only the finding it flaps on. See the issue.