[website] Non-reproducible website installs from gitignored lockfiles

### Search before asking

- [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar.

### Fluss version

main (development)

### Please describe the bug 🐞

We gitignore both lockfiles `website/pnpm-lock.yaml` and `website/package-lock.json` (`.gitignore` lines 46 and 50), so we never commit one. That means every `npm install` re-resolves all our version ranges against whatever npm is serving that day. Builds aren't reproducible, and the tree has no integrity checking. I'd like us to commit a lockfile and have CI install from it. pnpm later is a nice bonus, but optional.

I hit this twice in one sitting while reviewing a PR with changes in the website. A clean install pulled `@docusaurus/plugin-client-redirects` at `3.10.1` while `@docusaurus/core` stayed at `3.9.2`, and Docusaurus won't start unless every `@docusaurus/*` package matches:

```
Error: Invalid name=docusaurus-plugin-client-redirects version number=3.10.1.
All official @docusaurus/* packages should have the exact same version
as @docusaurus/core (number=3.9.2).
```

Then `@docusaurus/core` itself jumped `3.9.2 → 3.10.1` between two commands, with no edit to `package.json`. The tree moves under you, and someone has to stop and debug it each time. On top of that, a committed lockfile carries an integrity hash per package; without one, a bad transitive patch release installs silently with nothing to check it against.

## The fix

1. Drop both lockfile lines from `.gitignore`.
2. Commit the lockfile (`package-lock.json` if we stay on npm).
3. Switch the website CI job from `npm install` to `npm ci`, which installs from the lockfile and fails if it has drifted instead of re-resolving.

That's it. Builds are reproducible again and integrity checking comes back for free.

## Optional: pnpm

As a follow-up, not a requirement consider migration from npm to pnpm. A strict `node_modules` (no phantom hoisted deps) rules out a class of "works on my machine" bugs, including the half-npm/half-pnpm tree that gave me a duplicate-`joi` error while poking at this. It's also faster, uses far less disk, and has `minimumReleaseAge` to refuse brand-new releases as a hedge against a compromised one. Migration is basically `corepack enable` + `pnpm import`, then pin `packageManager` in `package.json`.

### Solution

_No response_

### Are you willing to submit a PR?

- [ ] I'm willing to submit a PR!

Start with .gitignore lines 46 and 50, then inspect website/package.json and the website CI job that currently runs npm install. Remove the lockfile ignores, commit website/package-lock.json, and change CI to npm ci; done means clean website installs use the committed lockfile and fail on dependency drift.

Written by the indexing model from the issue text.