chore: ignore package-lock.json, and record why

Work happens on both Windows and Linux, so a committed lockfile would do harm
rather than good here:

- Every dependency in package.json is pinned exactly (no ^ or ~), so a lockfile
  has no floating ranges to guard. A plain `npm install` resolves identically
  without it.
- The lock records platform-specific optional binaries for whichever OS built it
  (@rollup/rollup-linux-x64-gnu vs -win32-x64-msvc, for instance). Committed from
  one platform it is wrong on the other, and `npm ci` refuses rather than
  adapting, since reproducing the recorded tree exactly is its entire purpose.

That is a strict mechanism pointed at the wrong target: it would break installs
across machines while guaranteeing versions that were already exact. Cloning is
rare here, so the reproducibility upside is small and the cross-platform cost is
immediate.

Both .gitignore and README now state the reasoning, including when to revisit (a
dependency loosened to a range, or transitive drift exact pinning cannot control).
Silently ignoring it would have invited the same question again.

Verified: `git check-ignore -v package-lock.json` matches, and a regenerated
lockfile leaves `git status` clean.

.gitignore

@@ -36,7 +36,18 @@ node_modules
 dist
 out
 .env
+
 # Python (helper scripts)
 __pycache__/
 *.py[cod]
 .venv/
+
+# Package lock — deliberately NOT tracked.
+# Every dependency in package.json is pinned to an exact version (no ^ or ~), so
+# a lockfile has no floating ranges to guard against. What it would add instead is
+# trouble across machines: the lock captures the resolved tree including
+# platform-specific optional binaries (e.g. @rollup/rollup-linux-x64-gnu), so a
+# Linux-generated lock is wrong on Windows and vice versa, and `npm ci` refuses
+# outright when the lock and manifest disagree. Revisit this if a dependency is
+# ever loosened to a range or picks up meaningful transitive drift.
+package-lock.json