chore(cli): reconcile dev-only audit findings after the v8 lockfile repair

Wait for #795 to contain one valid lockfile and for #463 to resolve the production findings. Then rerun the production and full audits from a fresh install, classify each remaining advisory by dependency path and reachability, and record the smallest compatible remediation. Done means a follow-up implementation task exists only for a proven change; do not upgrade dependencies in this issue.

Context

The July audit mixed production and development-only findings, and its package/version list is stale.

Production fast-uri findings belong to #463. This issue owns only tooling used on developer machines and CI.

The current audit shows these dev-only paths:

• high: js-yaml through Commitlint;
• moderate: Vitest and qs through Stryker;
• low: esbuild through tsup.

They are not shipped in the CLI package. Their risk is CI/developer exposure, not end-user runtime exposure.

PR #795 changes the dependency graph but its committed lockfile currently has two YAML documents. Do not decide upgrades from that invalid graph.

Dependencies

• #463: production fast-uri remediation.
• PR #795: one valid regenerated lockfile.

Discovery required

After #795 has one valid lockfile and #463 is resolved:

1. run the production and full audits again;
2. record each remaining advisory, reachability and smallest compatible remediation;
3. separate a major test-framework migration from minimal transitive dependency remediation.

Decision criteria

• Address any remaining high/critical dev-tooling finding with the smallest compatible change.
• Treat Vitest 4 as a separate migration only if the rerun still requires it.
• Group Stryker or tsup updates only when their compatibility and test cost are proven.

Acceptance criteria

• #463 has resolved the production fast-uri findings.
• #795 lockfile has been repaired and the audit is reproducible from a fresh install.
• The refreshed audit classifies every remaining finding by dependency path and development/production reachability.
• A follow-up implementation task exists only for a proven, compatible remediation.

Boundary

No dependency upgrades in this issue. No forced Vitest major upgrade merely to satisfy an outdated audit snapshot.