chore(security): add OpenVEX for gosu findings in the Laminar Postgres image

[aivong-openhands]

Why

The Laminar subchart's database image, postgres:15, has 1 critical and 21 high Trivy findings with fixes available, and all 22 are Go standard-library CVEs in the gosu binary (v1.19.0, built with Go 1.24.6). They are flagged by toolchain version, not by use: govulncheck -mode=binary on the binary shows 21 are in packages not compiled into gosu and the remaining one (CVE-2026-39822, os) is never called. They cannot be fixed from our side, since gosu upstream only rebuilds for reachable vulnerabilities and docker-library/postgres#1350 (replace gosu with setpriv) is unmerged.

This adds security/vex/laminar-postgres-gosu.openvex.json, an OpenVEX document marking those 22 IDs not_affected with the per-CVE justification, plus a README with the evidence, scope and regeneration steps. Scanners that read VEX can then suppress them with a recorded reason instead of ad-hoc ignores.

Validation

• Trivy with the VEX — trivy image --vex ... postgres:15 goes from 2 critical / 82 high (1 / 21 fixable) to 1 / 61 (0 / 0 fixable). The 22 suppressed IDs are exactly the gosu findings, and the remaining no-fix findings are unchanged.
• Scope — postgres:15-alpine, which ships the same gosu, is suppressed the same way; an unrelated Go image (ghcr.io/squat/generic-device-plugin:2cc50b0) keeps all 25 of its findings.
• Evidence matches the shipped binary — the analyzed gosu has the same sha256 as the one in the current postgres:15 (postgres@sha256:c961aa28…).

This PR was drafted by an AI agent on behalf of the user.