fix(security): patch picomatch ReDoS in lovable_clone npm lockfile

[sergioestebance]

Summary

Adds npm overrides for picomatch in python/examples/lovable_clone/template to fix:

• fix(js): correct consumeUntilRole and red-team backtrack mutation #279: ReDoS vulnerability via extglob quantifiers (package-lock.json)

Note: pnpm-lock.yaml for the same directory is handled by PR #394.

Part of #400

Test plan

• npm install --package-lock-only succeeds
• CI passes

[sergioestebance]

Dependency Impact Assessment: picomatch override

1. WHERE IS THIS DEPENDENCY USED?

No source files in this repo import picomatch directly. Searched all .js, .ts, .jsx, .tsx, .mjs, .cjs, and .py files — zero results. picomatch appears only in lockfiles (package-lock.json, pnpm-lock.yaml) across several directories.

2. PRODUCTION CODE IMPACT

None. picomatch is not imported anywhere in javascript/src/ or python/scenario/. It exists only as a transitive dev dependency inside python/examples/lovable_clone/template/.

3. SCOPE: Examples only

This override affects only python/examples/lovable_clone/template/ — an example project template that gets shutil.copytree'd into a temp directory at runtime (lovable_agent.py:162-165). The template itself never runs npm install or npm run build programmatically. The lockfile exists so that users (or agents) who clone the template have a pre-resolved dependency tree.

4. VERSION JUMP SIZE — FLAG

This is the main risk. The override "picomatch": ">=2.3.2" resolved picomatch from 2.3.1 → 4.0.4 — a jump of two major versions.

Three transitive consumers in the lockfile request ^2.x:

• anymatch@3.1.3 → picomatch: "^2.0.4"
• micromatch@4.0.8 → picomatch: "^2.3.1"
• readdirp@3.6.0 → picomatch: "^2.2.1"

The npm override forces all of them to use 4.0.4 instead of 2.x. I checked whether picomatch 4.x breaks compatibility:

• Module format: Still CommonJS (main: "index.js", no "type": "module"), so require('picomatch') still works.
• Core API (picomatch(pattern), picomatch.isMatch()): Still present and unchanged in 4.x.
• Breaking changes in 4.0.0: Removed process global usage and os module (for browser compat). These are unlikely to affect Node.js-based consumers like anymatch/micromatch/readdirp.
• Breaking changes in 3.0.0: No documented API-level breaking changes found; appears to be an engine bump and internal refactor.

However, using >=2.3.2 is unnecessarily broad. A safer override would be ">=2.3.2 <3.0.0" to stay within the 2.x semver range that consumers expect. The fix version 2.3.2 exists and patches the ReDoS vulnerability. There is no reason to jump to 4.x.

5. PINNED VERSION COMMENTS

None found. No comments in the codebase mention picomatch version pins, constraints, or upgrade warnings.

6. TRANSITIVE vs DIRECT

Transitive only. picomatch is not listed in dependencies or devDependencies of the template's package.json. It enters the lockfile via anymatch → picomatch, micromatch → picomatch, and readdirp → picomatch (all part of the vite/chokidar file-watching stack).

7. FINAL VERDICT: LOW RISK — but the override range should be tightened

Classification: LOW RISK — this is a transitive dev-only dependency in an example template, not imported anywhere in production or test code.

Recommendation: Change the override from ">=2.3.2" to ">=2.3.2 <3.0.0" to avoid the unnecessary major version jump. The CVE fix is in 2.3.2, so there's no reason to allow resolution to 4.x. This eliminates the (low but real) risk of breaking the template's vite/chokidar dev tooling stack, which expects picomatch 2.x.

I will push this fix in a follow-up commit.

[sergioestebance]

CI green — all 6 checks pass (CodeQL Analyze x2, Validate PR Title, semantic-pull-request, evaluate, test). Ready for review.

[github-actions]

Automated low-risk assessment

This PR was evaluated against the repository's Low-Risk Pull Requests procedure and does not qualify as low risk.

The change modifies package.json and package-lock.json to override/pin transitive dependencies (picomatch and related packages) in the lovable_clone template. Dependency/lockfile changes can alter runtime behavior or integrations with third‑party packages and therefore do not meet the policy’s low‑risk criteria even though no auth, secrets, DB schema, or business logic were touched.

This PR requires a manual review before merging.