fix: add package-lock.json for npm ci in docs workflow

[Copilot]

The docs deployment workflow fails at npm ci step because package-lock.json is missing and explicitly gitignored.

Changes

• Add docs/package-lock.json: Generated lockfile (lockfileVersion 3) for deterministic CI installs
• Add docs/.npmrc: Configure legacy-peer-deps=true to resolve vitepress 1.5 + markdown-it-mathjax3 5.x peer dependency conflict
• Update .gitignore: Remove docs/package-lock.json exclusion to allow version control tracking

Context

npm ci requires an existing lockfile with lockfileVersion ≥ 1. The .npmrc configuration is necessary because vitepress 1.5 declares optional peer dependency on markdown-it-mathjax3 ^4, while package.json specifies ^5.0.0, causing npm ci to fail without the legacy-peer-deps flag.

Original prompt

The failing job encountered this error:

The npm ci command can only install with an existing package-lock.json or npm-shrinkwrap.json with lockfileVersion >= 1. Run an install with npm@5 or later to generate a package-lock.json file, then try again.

Solution:

1. Make sure your repository contains a package-lock.json file at its root.
2. If it's missing, run npm install locally, which will generate the package-lock.json.
3. Add and commit package-lock.json to your repository:

   git add package-lock.json
   git commit -m "Add package-lock.json for npm ci"
   git push

Why this works:
npm ci requires package-lock.json to ensure deterministic installs; without it, npm ci will always fail.

Reference your workflow: .github/workflows/docs.yaml@b068e7134577a4aa44139272646d95db928885c2—no change in the workflow is needed if you add package-lock.json as directed.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[Anselmoo]

Heads-up: I created #96 to track migrating docs away from legacy dependencies (math renderer and chart wrappers) to avoid the long-term need for 'legacy mode'. Please review #96 and consider the migration plan/checklist; the PR should be re-evaluated to avoid locking the docs into legacy behavior if a maintained alternative is viable.

[Anselmoo]

Request changes: prefer migration tracked in #96 over keeping legacy behavior. Please review the candidate migration options and prototype before merging so we avoid long-term legacy mode.

[Anselmoo]

Consider avoiding legacy-peer-deps=true if we can migrate dependencies instead; see #96 which tracks migration to KaTeX/MathJax v3 and ECharts + maintained wrappers.

[Copilot]

Understood. This PR provides an immediate fix to unblock the failing CI workflow. The proper migration to KaTeX/MathJax v3 and maintained ECharts wrappers should be handled in #96 as a separate effort involving research, prototyping, and testing.

If you prefer to wait for the migration rather than merging this temporary workaround, I can close this PR and the CI fix can be included as part of the #96 migration work.

[Copilot]

Heads-up: I created #96 to track migrating docs away from legacy dependencies (math renderer and chart wrappers) to avoid the long-term need for 'legacy mode'. Please review #96 and consider the migra...

I've reviewed #96. The migration plan looks comprehensive and is the right approach for long-term maintainability. This PR can be closed if you'd prefer to bundle the CI fix with the dependency migration work in #96, or it can serve as a temporary unblock while #96 is in progress. Let me know your preference.

Request changes: prefer migration tracked in #96 over keeping legacy behavior. Please review the candidate migration options and prototype before merging so we avoid long-term legacy mode.

This PR was intended as an immediate fix to unblock the failing docs deployment workflow. I agree that the migration tracked in #96 is the proper long-term solution. Should I close this PR in favor of addressing the CI failure as part of the #96 migration work instead?