build(deps-dev): bump @types/node from 26.1.1 to 26.1.2 in /infra in the minor-and-patch group across 1 directory

[dependabot]

Bumps the minor-and-patch group with 1 update in the /infra directory: @types/node.

Updates @types/node from 26.1.1 to 26.1.2

Commits

• See full diff in compare view

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 06a8113d89

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Keep the infra lockfile in sync

For infra CI, checked .github/workflows/ci.yml: the install step runs cd infra && bun install --frozen-lockfile, and bun install --help says --frozen-lockfile disallows lockfile changes. This line now requires @types/node 26.1.2, but infra/bun.lock still records the workspace dependency and package entry as 26.1.1, so the frozen install has to change or resolve the lockfile before the CDK build/synth job can run. Please regenerate and commit infra/bun.lock with this bump.

Useful? React with 👍 / 👎.

[krishagel]

🤖 pr-fix routine: blocked — cannot regenerate the lockfile in this environment

Diagnosis (confirmed, not a guess):

The only failing check is Validate CDK Infrastructure. Its log ends with:

error: lockfile had changes, but lockfile is frozen
note: try re-running without --frozen-lockfile and commit the updated lockfile

This PR modifies infra/package.json (@types/node 26.1.1 → 26.1.2) but does not touch infra/bun.lock, which still pins the old version:

infra/bun.lock:621:  "@types/node": ["@types/node@26.1.1", "", { "dependencies": { "undici-types": "~8.3.0" } }, "sha512-nxAkRSVkN1Y0..."],

So bun install --frozen-lockfile correctly refuses. CI on dev is green, so this is PR-caused, not a pre-existing base-branch failure.

The fix is one command — cd infra && bun install and commit the updated infra/bun.lock. I could not run it: registry.npmjs.org is denied by this session's egress policy (403 both directly and via the agent proxy), and generating a lockfile entry requires the package's real sha512 integrity hash from the registry. I will not fabricate one.

Systemic root cause (affects every open Dependabot PR here, not just this one):

.github/dependabot.yml declares package-ecosystem: "npm" for both / and /infra. This repo has no package-lock.json or yarn.lock — it uses bun.lock. Dependabot's npm ecosystem edits package.json only and has no idea how to update bun.lock, so every Dependabot PR desyncs the lockfile and fails --frozen-lockfile. That matches what's on the board: #1563 and #1572–#1576 are already sitting at pr-fix-stuck, and #1567/#1570/#1571 fail the same way.

Two options for a human:

1. Per-PR: run bun install (root and/or infra) on each branch and push the lockfile.
2. Once, permanently: switch .github/dependabot.yml to package-ecosystem: "bun" for both directories so Dependabot maintains bun.lock itself. I deliberately did not make this change — it re-shapes every future dependency PR and I can't validate it from here, so it should be your call.

The routine will not pick this PR up again until someone removes the pr-fix-stuck label.

---

Generated by Claude Code