Refresh HTTP cache policy and review website audit findings #261

Findings

A fresh lockfile-based npm audit reports32 high-severity dependency entries representing two root advisories:

• http-cache-semantics GHSA-ch52-4w7c-c8xp, affected range<=4.2.0. This website locks4.2.0 through cacheable-request. Registry4.3.0 is available; its upstream source corrects wildcard Vary handling.
• braces GHSA-vfj7-8cjw-p6xm, affected range<=3.0.3. Registry3.0.3 is still the latest3.x release, with no published fix in the advisory. The installed paths are build/development glob processing through chokidar/micromatch/fast-glob.

A constructed, network-disabled HTTP cache-policy control reproduces two incorrect stale reuses on actual4.2.0 for Vary: accept, * and Vary: *, accept. Standalone wildcard refusal and ordinary matching-header reuse controls pass. The identical four cases all pass on actual registry4.3.0. This establishes the specific dependency behavior and does not demonstrate a production user-data disclosure on the statically published site.

The existing preflight's success message also overstates its scope: it claims the dependency graph is secure after checking selected version floors and image-parser assets. That wording should report only the checks performed.

Acceptance

• Update the compatible HTTP-cache lock entry, preserve maintained Docusaurus patches and guard against reintroducing affected versions, including nested copies.
• Keep regression coverage for wildcard Vary in stale responses and successful ordinary cache reuse.
• Trace the unpatched braces exposure and record a specific maintainer decision without claiming the audit is clean or forcing an incompatible dependency downgrade.
• Make the preflight success message reflect its actual scope.
• Qualify the exact updated website source and publication; keep the separate signal-authentication documentation PR260 independently identified.