Bump jackson-bom to 2.21.4 to fix CVEs

[vastin]

Summary

• Bump jackson-bom from 2.21.1 → 2.21.4, fixing CVE-2026-54512, CVE-2026-54513, CVE-2026-54514, CVE-2026-54516, CVE-2026-54517, CVE-2026-54518 (release notes)
• Suppress CVE-2026-54515 in trivyignore (no fix in 2.21.x yet — Trivy DB references 2.21.5 which has not been released)
• Remove expired Netty CVE suppressions (already fixed by 4.1.135.Final bump in Bump Netty to 4.1.135.Final to fix CVE-2026-45416 and CVE-2026-44249 #1389)

Test plan

• PR build Trivy image scan passes
• If Trivy still flags CVE-2026-54514 or CVE-2026-54517 (stale Trivy DB), add suppressions for those as well

[github-actions]

Claude finished @vastin's task in 1m 24s —— View job

---

Claude PR Review

• Check prior review comments to dedupe (none found)
• Read the PR diff
• Verify Jackson 2.21.4 bump
• Verify CVE-2026-54515 suppression rationale
• Verify Netty CVE suppressions are stale/fixed
• Post findings

---

LGTM — small, focused, well-justified change. No blocking issues.

Verified:

• dependencyManagement/build.gradle.kts:38 bumps jackson-bom 2.21.1 → 2.21.4. Netty BOM at line 43 is already 4.1.135.Final (≥ the 4.1.133.Final fix referenced in the old suppressions), so removing those Netty entries is correct cleanup — they had also already passed expired_at: 2026-05-22.
• The remaining CVE-2026-54515 suppression is short-lived (expired_at: 2026-07-31, ~5 weeks from today 2026-06-26), which is appropriate for a "waiting on upstream" carve-out.
• Both daily-scan and pr-build trivyignore files are kept in sync.

Minor observations (non-blocking):

1. The PR body explicitly calls out that the Trivy DB may still flag CVE-2026-54514 / CVE-2026-54517 against 2.21.4 due to DB staleness. If the PR-build scan does flag them, prefer adding time-boxed suppressions (similar short expired_at to -54515) rather than long-lived ones — Jackson 2.21.x is on an active patch cadence and these should drop off once the Trivy DB catches up.

2. The two trivyignore files are now identical in content. Not worth changing in this PR, but if drift between daily-scan and pr-build becomes a recurring maintenance burden, a follow-up to share a common file (or generate one from the other) would reduce the chance of one getting updated without the other.

3. Consider noting in the suppression statement which Jackson release is expected to carry the fix (if known from the FasterXML tracker), so the next person reviewing the suppression doesn't have to re-discover that context. Not required.
   · Branch