chore(site): take in-range security updates in the lockfile

[Seungpyo1007]

Lockfile-only security update for the site. package.json is unchanged — every bump stays inside the ranges already declared.

js-yaml     4.1.1  -> 4.3.2      smol-toml  1.6.1  -> 1.8.0
nanoid      3.3.12 -> 3.3.19     svgo       4.0.1  -> 4.1.0
postcss     8.5.15 -> 8.5.28     vite       6.4.2  -> 6.4.3
css-select  5.2.2  -> 6.0.0      css-what   6.2.2  -> 7.0.0
sax         1.6.0  -> 1.6.1

npm audit goes from 9 vulnerabilities (1 critical, 7 high, 1 low) to 3.

Verified by building — CI does not

TechAPI's PR checks validate data but never build the site; the build only runs on deploy from main. So the site was built locally both ways, from a checkout without the million-file dump (astro build, skipping prebuild, which needs index.json's git history):

lockfile	npm ci	astro build	pages	dist files	warnings / errors
current	ok	ok	2	7	0
this PR	ok	ok	2	7	0

What is left, and why it is not in this PR

The remaining three — astro (critical), sharp (high), esbuild (low) — only clear with astro 5 → 7, a semver-major upgrade that needs its own migration and review.

Actual exposure is low in the meantime:

• The critical astro advisories are XSS through define:vars and replay of server-island parameters. The site uses neither — no define:vars anywhere in site/src, and it is a static build (no output: server, no adapter).
• sharp, esbuild, and most of what this PR fixes (vite / esbuild dev servers, launch-editor, postcss source maps) run on the build machine, not in what visitors download.

Refs #1

Closes #19

[Seungpyo1007]

Output check: the two builds (current lockfile vs this PR) were compared file by file. All 7 files in dist/ — including the content-hashed _astro/*.js and *.css bundles — are byte-identical. The update changes nothing a visitor downloads; it only changes what runs on the build machine.