chore(deps): security modernization of dev toolchain and transitive pins

[prisis]

Summary

Reduces yarn audit findings on the alpha branch as far as can be done safely without touching the action's runtime behaviour. The strategy was: upgrade the old Jest-era dev toolchain to current majors, and add a yarn resolutions block to force patched versions of vulnerable transitive packages. No production/runtime dependency majors were bumped (see "Remaining advisories" for why).

Audit results (yarn audit)

Severity	Before	After
critical	55	0
high	204	5
moderate	116	13
low	19	2
total	394	20

Dependency count dropped from 2033 to ~1659.

What changed

Dev dependency upgrades (clears the bulk of the old jest 27 tree: @babel/traverse, braces, json5, lodash, micromatch, semver, tmpl, ws, cross-spawn, form-data, ...):

• jest 27 -> 30
• jest-circus 27 -> 30
• ts-jest 27 -> 29
• @types/jest 27 -> 30
• eslint-plugin-jest 26 -> 29

Yarn resolutions to force patched transitive versions:

• Global: semver, lodash, braces, micromatch, cross-spawn, json5, form-data, tmpl, moment, brace-expansion (2.0.3), minimatch (9.0.9), minimist (1.2.8), chrono-node, ip (latest available)
• Scoped (nested ReDoS copies that a flat pin could not unify across majors): anymatch/picomatch -> 2.3.2, strip-ansi/ansi-regex -> 5.0.1, wrap-ansi/ansi-regex -> 5.0.1

Build & tests

Both build and test were already failing on alpha before this PR, for reasons unrelated to dependencies, and they fail identically after this change (no regression):

• yarn build (tsc) fails with 7 pre-existing TS2339 errors in src/github-manager.ts (octokit.git / octokit.repos / octokit.pulls do not exist on the bare @octokit/core Octokit type).
• yarn test (jest) fails because the test files import from ../lib/*, which is never produced (tsconfig.json sets noEmit: true). Jest 30 + ts-jest 29 themselves load and run correctly.

This PR does not attempt to fix those pre-existing failures; it only ensures the dependency changes do not make them worse.

Remaining advisories and why they cannot be fixed here

All remaining findings are pinned by the runtime @octokit/action@3 and @actions/* chains. Fixing them requires major runtime upgrades that change the action's behaviour and cannot be verified end-to-end in this environment, so they were deliberately left alone:

• ip (high, 1 path, via @octokit/action) — abandoned package, no patched version exists (advisory patched: <0.0.0). Would only disappear by upgrading @octokit/action to v8 (which drops the proxy-agent/pac-resolver chain).
• @octokit/request, @octokit/request-error, @octokit/plugin-paginate-rest (moderate, via @octokit/action) — structurally tied to @octokit/action@3 / @octokit/core@3. The patched versions require @octokit/core@5+, i.e. @octokit/action@8. That upgrade was rejected because v8's @octokit/action auto-authenticates from the Actions environment and ignores the explicit auth option the code passes from the github_token input — a behavioural regression for users supplying a custom token, which cannot be validated here.
• undici (moderate, via @actions/core / @actions/tool-cache) — pulled by @actions/http-client@2, which is built for undici 5.x. The patched undici (>=6.23) only ships with @actions/http-client@4; forcing it is an unverifiable runtime major bump. These run inside trusted GitHub Actions runners against api.github.com, so real-world exploitability is low.
• uuid (moderate, via @actions/tool-cache) — tool-cache@1.7.2 pins uuid@^3; forcing uuid 11 changes the module's API (default vs named export) and would break tool-cache.
• @tootallnate/once (low, via @octokit/action) — part of the same @octokit/action@3 proxy chain; disappears only with the rejected v8 upgrade.

Note: vm2 (previously the largest critical cluster, via @octokit/action@3's pac-resolver) is no longer reported by the audit feed and no longer surfaces as critical. It remains on disk via the same @octokit/action@3 chain and would be fully removed by the (deliberately deferred) @octokit/action@8 upgrade.

Chosen strategy

Stayed on yarn classic with upgrades + resolutions. A pnpm migration was considered but rejected: it would not change the dependency surface (the remaining advisories are pinned by runtime majors, not the package manager), while adding a large, risky, unverifiable change.

🤖 Generated with Claude Code