Fix vulnerable transitive deps (rollup ^4.60.4 to avoid socket fix regression)

[marcocastignoli]

Summary

Re-applies the CVE fixes that PR #34 attempted via socket fix, but pins them through explicit package.json overrides and — crucially — bumps rollup past the 4.59.x line that caused the continuous-reload regression on staging.

What changed in package.json

"overrides": {
  "bn.js":     "^5.2.3",
  "fast-uri":  "^3.1.2",
  "lodash":    "^4.18.1",
  "picomatch": "^4.0.4",
  "postcss":   "^8.5.10",
  "rollup":    "^4.60.4"
}

npm audit reports found 0 vulnerabilities after these overrides; Socket's socket npm ci runs clean too.

Why socket fix broke staging — root cause

socket fix bumps each flagged package to the minimum CVE-safe version. For rollup, that's 4.59.0 — and 4.59.0/4.59.1 have known bugs in chunk assignment and chunk-hash stability that were only fixed in the 4.60.x line:

• v4.59.1 — "Fix a crash when using lazy dynamic imports with moduleSideEffects:false"
• v4.59.1 — "Fix chunk assignment for deoptimized module with dynamic import"
• v4.60.2 — "Resolve a variable rendering bug when generating different formats from the same build" (#6350)
• v4.60.4 — "Improve stability of chunk hashes" (#6362)

This explains "works locally, breaks on staging": Vite uses esbuild in dev mode (npm run dev) and only invokes rollup for the production build, so the buggy 4.59.0 output never ran locally.

Pinning rollup ^4.60.4 clears the CVE and the regression in one move.

Why use overrides instead of socket fix

• socket fix leaves no record in package.json of why versions are pinned, so future renovate/lockfile-regenerations can silently undo the bump.
• It also picks min-safe versions automatically, with no way to skip buggy ones (like rollup@4.59.x).
• Explicit overrides document intent and survive lockfile regenerations.

Test plan

• npm audit → 0 vulnerabilities
• socket npm ci succeeds (no risks flagged)
• npm run build succeeds against .env.build.staging
• Deploy to staging and confirm the continuous-reload issue is gone
• Verify the verification flow works end-to-end

Pre-existing tsc error in app/components/verification/ImportFromEtherscan.tsx:53 is present on origin/staging and unrelated to this PR (build pipeline doesn't run tsc, only react-router build).

[cloudflare-workers-and-pages]

Deploying verify-sourcify-dev with    Cloudflare Pages

Latest commit:	4b646e6
Status:	✅  Deploy successful!
Preview URL:	https://ddef70e7.verify-sourcify-dev.pages.dev
Branch Preview URL:	https://fix-vulnerable-deps.verify-sourcify-dev.pages.dev

View logs