Possible fix(deps): 3 vulnerable dependencies in package-lock.json

I think there may be a problem in `actions/status-checker/package-lock.json` around line 3601.

Vulnerability: CVE-2026-12151 (HIGH) in undici 5.29.0, pinned in actions/status-checker/package-lock.json (lines 3601-3612). The undici WebSocket client enforces maxPayloadSize only against the cumulative byte count of fragments in a message but applies no limit to the number of fragments. A malicious or compromised WebSocket server can stream an unbounded series of small or empty continuation frames, each passing per-frame and cumulative-size validation, causing unbounded memory growth and memory-exhaustion denial of service in the client process. Impact: any code path in the status-checker that opens a WebSocket via undici (new WebSocket(...) / WebSocketStream) toward an attacker-controlled or MITM'd endpoint can be remotely crashed or caused to exhaust runner memory, disrupting CI/CD pipelines. Risk level: HIGH — remotely triggerable DoS, no workaround exists; only a version upgrade remediates it. Nuance: the advisory text states releases from undici 6.17.0 onward are affected, so 5.29.0 may fall outside the vulnerable range (a possible scanner-range artifact), but the 5.x line has no patched release for this issue and the scanner's fixed-version requirement is >= 6.27.0, so upgrading is the correct remediation regardless. Note a discrepancy between the finding's fixed version (6.27.0) and the advisory text (>= 6.26.0); 6.27.0 satisfies both.

Something like this might fix it:

```diff
Upgrade undici to a patched version. The flagged file is a lockfile, so regenerate it with npm instead of hand-editing integrity hashes.

1. Bump the dependency in actions/status-checker/package.json:

--- a/actions/status-checker/package.json
+++ b/actions/status-checker/package.json
@@
"dependencies": {
- "undici": "^5.29.0"
+ "undici": "^6.27.0"
}

2. Regenerate the lockfile (this updates the flagged lines 3601-3612 automatically):

cd actions/status-checker
npm install undici@^6.27.0
# verify: npm ls undici && npm audit

Resulting lockfile change:

--- a/actions/status-checker/package-lock.json
+++ b/actions/status-checker/package-lock.json
@@
"node_modules/undici": {
- "version": "5.29.0",
- "resolved": "https://registry.npmjs.org/undici/-/undici-5.29.0.tgz",
- "integrity": "sha512-"
+ "version": "6.27.0",
+ "resolved": "https://registry.npmjs.org/undici/-/undici-6.27.0.tgz",
+ "integrity": "sha512-"
}

Notes: commit both package.json and package-lock.json; do not manually edit package-lock.json (integrity hashes must come from npm); undici v5 -> v6 includes breaking API changes, so run the project's tests against the upgraded version; re-run the scanner afterward to confirm the finding is cleared. Alternatively, jump to >= 8.5.0 to stay on the latest supported major line.
```

For reference: rule `CVE-2026-12151`. Rated high.

I may be wrong about this one — closing it costs you nothing if so.

---
*Found with automated scanning ([RedGem](https://code.redgem.net)) and reviewed before opening. If it is not useful, closing it is completely fine.*

Start with actions/status-checker/package.json and actions/status-checker/package-lock.json around the undici entry, then run npm ls undici and npm audit from actions/status-checker. Update both dependency files through npm, run the project's tests to check the v5-to-v6 compatibility, and confirm the scanner finding is cleared.

Written by the indexing model from the issue text.