chore(ci): regenerate the lockfile and gate deploys on critical vulns

Review follow-up.

Lockfile: the previous commit pruned the surfer subtree by hand and left
orphaned nested entries behind (node_modules/cloudron-surfer/node_modules/*,
plus children of removed parents such as @cloudron/pankow's filesize and
express-session's cookie). Regenerated from the unmodified main lockfile with
`npm install --package-lock-only --legacy-peer-deps`, so the lock is npm's own
output rather than an edit. No dangling entries remain.

Publish workflow: added a blocking `npm audit --audit-level=critical` step
between install and build. Critical rather than the suggested default/low: the
tree carries 102 advisories at low/moderate/high that have no non-breaking fix
(mostly the Gatsby 5 build toolchain), so a low gate would fail every deploy
from the first run. The tree is now clear of criticals, having bumped the two
that were live, both within their parents' existing ranges:

- proxy-addr 2.0.7 -> 2.0.8 (GHSA-jqcg-44mw-7w3h, via express ~2.0.7)
- shell-quote 1.8.1 -> 1.12.0 (GHSA-w7jw-789q-3m8p, GHSA-395f-4hp3-45gv, via
  react-dev-utils ^1.7.3)

.pre-commit-config.yaml: gitleaks hook pinned to v8.30.1 for staged-content
secret scanning. Developer-side only - `pre-commit install` per clone.

Verified: `npm ci --legacy-peer-deps` clean against the regenerated lock,
`npm audit --audit-level=critical` exits 0, build 136 pages, typecheck clean,
lint unchanged at the 8 pre-existing files.

.pre-commit-config.yaml

@@ -0,0 +1,12 @@
+# Secret scanning for staged content, so a credential is caught before it is
+# committed rather than after it has been pushed and published.
+#
+# gitleaks is pinned to an exact tag: a floating rev would pull whatever the
+# hook's upstream does next into every contributor's commit path.
+#
+# Install once per clone: `pre-commit install`.
+repos:
+  - repo: https://github.com/gitleaks/gitleaks
+    rev: v8.30.1
+    hooks:
+      - id: gitleaks