ci: harden the bun audit gate (bun 1.4.0, registry retries, timeout)

[larryro]

Why

After #3210 cleared the Trivy gate, the Security workflow's Bun audit gate is the last red on main (and on PR #3210's own run, job 100945897852):

bun audit v1.3.12
@faker-js/faker  <=10.4.0
  workspace:@tale/platform › @stoplight/prism-http
  high: Faker: helpers.fake exploitable into arbitrary code execution - GHSA-qxc2-j82w-r537
1 vulnerabilities (1 high)

That copy is @faker-js/faker@5.5.3, pinned exactly by postman-collection → @stoplight/http-spec → @stoplight/prism-http (the mock server), which is a devDependency of @tale/platform and never in a shipped image. No upstream release lifts the pin: the latest postman-collection (5.3.1) still pins 5.5.3, and prism-http 5.16.0 still depends on http-spec ^7.1.0 → postman-collection ^4.1.3. Prism itself already resolves the patched 10.5.0.

The gate runs bun audit --prod, which is supposed to exclude exactly this. Before bun 1.4 it did not when run from a workspace root — oven-sh/bun#26675 ("bun audit --prod won't work in monorepos": workspace members' devDependencies reported as production), fixed in 1.4 by oven-sh/bun#38333. The job pins bun 1.3.12.

What changed

.github/workflows/security.yml: the Bun audit job's setup-bun pin goes to 1.4.0, with a comment saying why it is deliberately newer than the build jobs' 1.3.12. Nothing else — the Trivy job (which already classifies dev deps correctly) and the gate command are unchanged, and no --ignore is added.

Verified locally (bun 1.4.0, direct registry)

• On the pre-fix(deps): patch the fast-uri and mysql2 high-severity advisories #3210 lock (6846351): bun audit --prod --audit-level=high → 5 vulnerabilities (5 high): the four fast-uri advisories via workspace:@tale/platform > ajv > fast-uri and mysql2 via workspace:@tale/platform > mysql2 and > better-auth > mysql2 — i.e. 1.4.0 still sees workspace production findings, root and member alike. No faker.
• On the current lock (fix(deps): patch the fast-uri and mysql2 high-severity advisories #3210 applied): No vulnerabilities found (checked 1651 packages, 6 below --audit-level=high), exit 0.

This PR touches security.yml, so the Security workflow runs on it and the gate proves itself before merge.

Also in this PR: survive a degraded advisory registry

The first CI run of this PR failed the same gate for a different reason — error: POST https://registry.npmjs.org/-/npm/v1/security/advisories/bulk - 503 — and the re-run was cancelled by the job's 5-minute budget while the report step hung on that endpoint (probing it from here: alternating 1.5 s 200s and 60 s hangs). A registry outage must not read as a finding, so the second commit:

• runs the gate up to 3 times, 30 s apart, each attempt capped at timeout 240; only a hung attempt (exit 124) or a transport-error line is retried — a run that lists advisories still exits 1 on the first pass (stderr now joins the tee'd log so the check can see the error line);
• caps the informational report step at 4 minutes (continue-on-error already) and raises the job budget from 5 to 20 minutes so the retries fit.

Simulated against a fake bun (flaky 503 → pass on 3rd try; hang → retried once then pass; permanent 503 → red after 3; real finding → red on the 1st call; clean → green on the 1st call): all five behave as intended.