[ValentaTomas]

Moves every Bun pin from 1.2.x to 1.4.4: bun-version in code-quality.yml, test.yml and sync-infra-specs.yml (1.2.20), the Dockerfile's oven/bun deps stage (1.2.20), and packageManager (1.2.0). 1.4.4 is the version the eMudhra intermediate CA key-compromise disclosure lists as patched for Bun's bundled trust store; the runtime image is Node-only and unchanged. This is a two-minor Bun jump that could not be run locally, so CI is the check: watch bun install --frozen-lockfile against the existing bun.lock (lockfile format and install defaults moved across 1.3/1.4) in Code Quality, Test and the Container build.

[cursor]

PR Summary

Medium Risk
Two-minor Bun upgrade can break frozen-lockfile installs or Docker deps stage behavior; runtime stays Node-only.

Overview
All Bun pins move to 1.4.4: bun-version in code-quality, test, and sync-infra-specs workflows (from 1.2.20), oven/bun in the Dockerfile deps stage (from 1.2.20), and packageManager in package.json (from 1.2.0). No app or lockfile changes; CI must confirm bun install / bun install --frozen-lockfile still work on 1.4.4.

^{Reviewed by Cursor Bugbot for commit 2b140fb. Bugbot is set up for automated code reviews on this repo. Configure here.}

[claude]

I reviewed this PR and didn't find any bugs. A code owner should still look at it, because it jumps Bun by two minor versions, the author couldn't test that locally, and the security reason in the description links to an outside disclosure page that I didn't verify.

What was reviewed:

• Every Bun pin is now 1.4.4: all six setup-bun steps, the Dockerfile deps stage and packageManager. No other pin remains, apart from the @ types/bun dev dependency.
• bun.lock already uses lockfileVersion: 1 with a configVersion field, so bun install --frozen-lockfile should read it as is. CI is still the real test of that.
• The Bun binary from the deps stage is also copied into the build stage for bun scripts/check-app-env.ts, so the bump reaches the build as well as dependency install.
• The cache keys hash only bun.lock, not the Bun version, so the restore-keys prefix may reuse a cache from 1.2. That's harmless, because a mismatched cache just gets refetched.

Extended reasoning...

The change bumps the Bun version in three CI workflows, the Dockerfile deps base image and the packageManager field in package.json. It doesn't touch application code, auth or data handling. It does change the toolchain that installs dependencies and builds the container image, so it matters for the supply chain. The CODEOWNERS * rule covers every changed file, so I can't approve it on my own. The PR also says the jump wasn't tested locally, and it rests on an outside security claim I couldn't confirm.