fix(deps): repair corrupted pnpm lockfile and reduce recurrence risk

[Th3Mouk]

Summary

main's pnpm-lock.yaml has had a duplicated tinyglobby@0.2.17 mapping key since 2026-06-03 (commit 9e8d3db, PR #44 — a grouped Dependabot update bumping 5 dev dependencies at once). That's invalid YAML, and it breaks pnpm install --frozen-lockfile — the very first step of the validate CI job.

Every push-triggered CI run on main since that commit has failed at that first step, before lint, typecheck, or tests ever get a chance to run. This includes ordinary human commits, not just Dependabot ones. Fixing that first step peeled back three more layers that had been silently broken the whole time (see below) — CI hadn't actually completed on main in three months.

Why this merged despite CI being red

main has no branch protection (confirmed via the API — 404 Branch not protected). The Dependabot auto-merge workflow uses gh pr merge --auto, which only waits for required status checks. With none configured, GitHub considers a PR mergeable as soon as there's no conflict — independent of whether validate passed. Concretely, on PR #44: validate (22.12.x) and validate (24.x) both show FAILURE, completing at 23:54:21 / 23:54:26, while the PR's mergedAt is 23:54:12 — merged before its own CI even finished.

This PR intentionally does not touch that. No branch protection, no required status checks, nothing that would make auto-merge (or a manual merge) wait or block — per explicit instruction to leave that exactly as-is. It only fixes the corruption itself and reduces (not eliminates) the odds of it recurring, via levers that don't touch the merge path.

Changes

• pnpm-lock.yaml / npm-shrinkwrap.json: regenerated from the current package.json, which was never itself corrupted — only the lockfile's Dependabot-applied patch was. pnpm install --frozen-lockfile now succeeds.
• .github/dependabot.yml: removed the prod-dependencies / dev-dependencies groups for the npm ecosystem. A grouped, multi-package update is the most likely trigger for this class of Dependabot+pnpm lockfile-patching bug; single-package PRs are smaller, safer, more independently-verifiable patches. github-actions grouping is untouched — different ecosystem, not implicated here.
• src/validation/policies.ts, src/workspace/schema/repository.ts: a dead import and an unnecessarily-exported schema, both pre-existing and unrelated — only surfaced now because lint/knip haven't actually run against main in three months.
• .github/workflows/ci.yml: two related fixes.
  • npm install -g npm@11.19.1 added on every leg: the npm bundled with 22.12.x (10.9.0) crashes ("Cannot read properties of null (reading 'edgesOut')") inside the npm install --package-lock-only that scripts/sync-npm-shrinkwrap.mjs runs — a real npm Arborist bug, reproduced against this repo's unmodified package.json in matching Linux containers, unrelated to any change here. It's invoked both by test:npm-shrinkwrap and, unconditionally on every leg, by test:pack's prepack hook.
  • pnpm test:npm-shrinkwrap pinned to the 24.x leg only: even a non-crashing npm resolves a genuinely different answer on 22.12.x than on 24.x, because a transitive devDependency (@napi-rs/wasm-runtime) gates its newest release behind engines.node: ^22.13.0 || >=23.5.0, which 22.12.0 satisfies neither branch of. There is no single npm-shrinkwrap.json both legs would agree is current, so the check needs one authoritative leg — same pattern already used for pnpm test / pnpm test:coverage:ci. test:pack itself needed no such scoping: its --write mode doesn't compare against the committed file, so the per-leg resolution difference doesn't matter there.
• src/adapters/git/git-adapter.ts: fixed a separate, unrelated regression found while getting this PR green — repo git pull's autostash-conflict detection string-matched "Applying autostash resulted in conflicts", but git 2.55 (running in CI) reworded that message. Real conflicts were silently going undetected (status: "updated" instead of a thrown error), leaving conflict markers in the working tree. Reproduced across git 2.39/2.45/2.50/2.55 in matching containers; "resulted in conflicts" is the one substring present in both the old and new wording, and --ff-only already rules out the pull's own merge ever producing that text.

Side effect

Properly regenerating the lockfile also re-resolves shell-quote to 1.10.0 (from 1.8.3, already within the existing ^1.8.3 range in package.json) — which happens to fix two unrelated security advisories (one critical, one high) that were stuck because the broken lockfile prevented any resolution from moving for three months. pnpm audit --prod now reports no known vulnerabilities. @types/shell-quote is dropped from devDependencies since shell-quote@1.10.0 ships its own types natively.

Residual risk (stated plainly)

Without something gating the merge path — which is explicitly out of scope here — a future grouped or otherwise unlucky Dependabot update could corrupt the lockfile again and still merge. This PR reduces the odds; it does not eliminate them.

Test plan

• pnpm install --frozen-lockfile (the exact command CI runs) succeeds
• pnpm check fully green locally: knip, lint, format, typecheck, audit, build, test, runtime-dependencies, smoke, pack
• CI green on this PR, both matrix legs (validate 22.12.x, validate 24.x)

[codecov-commenter]

Welcome to Codecov 🎉

Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests.

Thanks for integrating Codecov - We've got you covered ☂️