ci(release): accept the unfixed arm64 Chromium CVEs in the image scan

[rmyndharis]

The v0.23.1 image scan failed on linux/arm64 with 33 HIGH findings, blocking promotion and the GitHub Release. This accepts them temporarily so the release can ship, with the same shape and the same honesty as the earlier chromium batch in this file.

Why the build is not at fault

• Eleven ids across chromium, chromium-common and chromium-sandbox, which is why eleven produce thirty-three findings.
• arm64 only, by construction: Chrome for Testing publishes no linux-arm64 build, so amd64 uses CfT while arm64 installs Debian's chromium. The amd64 scan passed.
• The image has 151.0.7922.137-1~deb12u1; Trivy names 151.0.7922.169-1~deb12u1 as fixed. The release build fetched from bookworm-security with no cached apt layer, visible as real Get: lines in the build log and no CACHED marker on the production stage, and installed the newest version that exists. I read the security mirror's own package index directly: it still serves .137 for both architectures. There is nothing to upgrade to, and rebuilding today produces the identical image.

Exposure, not talked down

Eight of the eleven are arbitrary or remote code execution in the renderer: v8 type confusion (76038, 76047), a v8 miscalculation (76043), Dawn (76036), a WebGL use-after-free (76045), a use-after-free (76040), a race condition (76044) and link following (76037). One is a site isolation bypass (76033) and two are information disclosure (76039, 76041).

Unlike the earlier batch, where two of four were sandbox escapes that --no-sandbox made irrelevant, none of these are neutralised by how the container runs. Chromium renders content the sender controls, so a crafted message is a plausible path to code execution as the openwa user inside the arm64 container, with the container itself as the only confinement boundary. This is accepted deliberately to ship, not because it is harmless.

Drop condition

All eleven come out the moment bookworm ships chromium >= 151.0.7922.169, tracked at the Debian security tracker link in the file, and the scan is re-run without them before assuming they are gone. That is what happened to the previous batch, which was added and then removed once Debian caught up.

Verification

• The eleven ids were extracted from the failing job's own output, not guessed. Cross-checked two ways: each id appears exactly three times in the findings table, and three packages times eleven ids equals the reported total of 33.
• .trivyignore now holds fourteen ids with no duplicates against the three already there.
• check:audit and the docs lane (264 tests) pass.