update cost models to epoch 638 and fix npm audit findings

[lisicky]

Cost models — epoch 638

The epoch-638 hard fork extended all three cost model lists and changed a few values. Ours were
the pre-fork ones:

	before	after
PlutusV1	166	332
PlutusV2	175	332
PlutusV3	297	350

Taken from Koios (mainnet, epoch 647), cross-checked against its cli_protocol_params endpoint
and against preprod — all three agree. Our previous values match mainnet epoch 637 exactly,
which confirms the ordering and encoding are unchanged; only the data moved. The transition is
sharp at 638 (637 = old, 638 = new).

⚠️ Worth a second pair of eyes before merge. I could not reproduce a real post-638
transaction's script_data_hash to prove the new values end-to-end — I checked several recent
blocks and none contained a Plutus transaction. The evidence is four agreeing sources plus
precedent (V3 already grew 251 → 297 by on-chain update, which this repo tracked in Dec 2024),
not a direct on-chain check. If you have a post-638 tx with scripts, that would settle it.

Test expectations

Cost models feed the script data hash, so script-integrity-hash expectations move with them.
Those values are snapshots of our own output — nothing in the file documented that, which makes
"regenerate them" look circular.

So this also adds two tests that verify the language-view encoding against vectors quoted
verbatim from the Conway CDDL, including PlutusV1's two quirks (indefinite-length list wrapped in
a bytestring, language id encoded twice). Those vectors are independent of our implementation and
match byte-for-byte. With the encoding pinned, a cost model update only moves the input data, and
the snapshots can be regenerated with confidence. The file now says so.

npm audit — 17 → 12

Fixed:

• tar (critical) — arbitrary file overwrite via hardlink path traversal. 7.2.0 → ^7.5.22
  in scripts/mesh-cli, not a major bump.
• brace-expansion (high ×2) — via an override to ^2.1.3.
• js-yaml, linkify-it, postcss (high) — npm audit fix, all dev-only.

Note package-lock.json was regenerated, hence the large diff.

What is left, and why it cannot be fixed here

Six of the remaining twelve are one defect wearing five extra hats:

@meshsdk/provider → @utxorpc/sdk → @connectrpc/connect-node → undici   (high)

undici is patched only in ≥6.23/6.24/6.27 depending on the advisory, and the 5.x line ends at
5.29.0 with no backport. Every connect-node 1.x release pins undici@^5.x, so bumping within
1.x changes nothing. connect-node 2.x drops undici entirely and would fix it — but
@utxorpc/sdk pins connect-node: 1.4 exactly, in every published version including the latest
0.8.2, and its 1.0.0-alpha.1 still asks for ^1.3.0. Forcing 2.x past that pin means a
breaking connect-rpc API change in a production path with no integration coverage, so it would
fail silently rather than in CI.

The unblocking order is upstream: @utxorpc/sdk → @meshsdk/provider → the bump here.

The other six are four dev-only @vercel/style-guide entries (fix is a major downgrade to
0.1.0), ip-address behind @cardano-sdk/core, and esbuild, which tsup pins.