build: track package-lock.json for reproducible installs

[SunsetDrifter]

Why

The lockfile is currently gitignored, so every install — local, PR CI, and the prod Docker build — re-resolves the ^ ranges in package.json from scratch. Builds aren't reproducible (the same commit can pull different transitive versions build-to-build), and there's no fast/pinned install path.

Second of a short series addressing slow docs builds/deploys. Foundation for switching CI/Docker to npm ci in a follow-up.

What

• Stop gitignoring package-lock.json; commit a freshly regenerated one (npm install --package-lock-only, so node_modules was untouched).
• Document the convention in CLAUDE.md: regenerate + commit the lockfile alongside any package.json dependency change.

Safety

• No version changes. Fresh resolution is identical to what's been building (next 16.1.6, react 19.2.4, shiki 0.14.7, tailwindcss 3.4.19, framer-motion 11.18.2, mermaid 11.15.0…). Pinning locks in current reality.
• pr-build CI validates the pinned tree with a full npm run build.

Heads-up for contributors

• Once merged, dependency changes must include the updated lockfile. Today npm install reconciles silently; once the follow-up switches CI to npm ci, an out-of-sync lockfile will fail the build (by design).
• npm audit reports 15 pre-existing vulnerabilities (3 low / 5 moderate / 7 high). Not introduced here — the floating tree already carried them; committing the lock just makes them visible. Triage separately (no npm audit fix in this PR).

Test plan

• Lockfile regenerated without touching node_modules
• Fresh resolution matches current building versions (no drift)
• pr-build CI green (full npm run build against the tracked lock)

[coderabbitai]

Warning

Review limit reached

@SunsetDrifter, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 4 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 37bb9a98-3d98-4d50-ac36-d3328e134bd3

📥 Commits

Reviewing files that changed from the base of the PR and between 25898dc and 5ef3f1f.

⛔ Files ignored due to path filters (1)

• package-lock.json is excluded by !**/package-lock.json

📒 Files selected for processing (2)

• .gitignore
• CLAUDE.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch docs/track-lockfile

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}