fix(build): keep runtime updates within node limits

[branarakic]

Summary

• retain the dependency-closure runtime build introduced by fix(core,mcp): escape all C0 control chars + DEL in RDF literals (#416) #1617 while explicitly excluding @origintrail-official/dkg-evm-module
• make the runtime package plan a first-class module consumed by both the updater build and its regression test
• replace Shiki's full 347-language/66-theme bundle with the 21 supported grammars and two UI themes
• bound the existing Node UI build to a measured 896 MB V8 old-space ceiling

Why

The testnet-canary rollout of #1659 exposed two code-side regressions in constrained node-host updates:

1. dkg-chain has an optional workspace dependency on the EVM module, so the runtime dependency closure began running Hardhat/solc despite the updater's no-Hardhat invariant.
2. import('shiki') still placed Shiki's full language/theme registry in Vite's graph; the runtime allow-list limited initialization, not the build graph. Together with a 4096 MB V8 ceiling, this let a UI build dominate the 1.5 GiB service cgroup.

Observed during the live four-core rollout:

• beacon-03: runtime package build timed out after about 540s
• beacon-04: runtime package build timed out after about 600s
• active slots remained untouched and both nodes retried
• constrained service cgroups entered sustained memory.high throttling

The corrected runtime plan selects 17 of 50 workspaces and invokes no Hardhat build. The fine-grained Shiki bundle reduces generated JS from 323 files / 13.66 MB to 23 files / 5.97 MB. Four measured UI builds succeeded at the 896 MB heap ceiling, with peak RSS reduced from 1.289 GB to roughly 1.229–1.261 GB.

Validation

• pnpm run build:runtime:packages (17 workspaces, no Hardhat)
• pnpm run build:runtime
• pnpm --dir packages/node-ui test (2,136 passed, 38 skipped)
• pnpm --dir packages/cli exec vitest run test/node-ui-static.test.ts test/auto-update.test.ts (113 passed)
• pnpm test:scripts (55 passed)
• all 21 supported syntax aliases and both themes rendered through the real highlighter
• four measured UI builds at the 896 MB heap ceiling
• git diff --check

[otReviewAgent]

🟡 Issue: Make the runtime build plan a first-class module instead of extending the shell literal

What's wrong
This change fixes the immediate build scope by bolting one more filter onto an already large shell command, then adds a test that has to parse that command back into structured data. That makes release-build policy harder to maintain because the real model is not represented anywhere directly; future changes have to reason about JSON string escaping, shell quoting, pnpm filter semantics, and the test's regex tokenizer all at once. The cleaner move is to make the build plan data, not shell text.

Example
Adding the next runtime package or exclusion now requires editing an opaque package.json command, preserving the shell quoting shape expected by shellTokens, and potentially updating the separate REQUIRED_RUNTIME_PACKAGES list. The build policy exists as shell text first, with the test reverse-engineering it after the fact.

Suggested direction
Extract the runtime package include/exclude filters into scripts/lib/runtime-build-plan.mjs or a dedicated scripts/build-runtime-packages.mjs. Have the npm script delegate to node ... and have the test validate the exported/generated pnpm args. That deletes the bespoke shell tokenizer and gives the release build one canonical, structured source of truth.

For Agents
Look at package.json build:runtime:packages and scripts/lib/__tests__/runtime-build-plan.test.mjs. Preserve the selected workspace set and the exclusion of @origintrail-official/dkg-evm-module, but move the include/exclude filters into a small runtime-build-plan module or script that exposes typed arrays/functions for run build and list --json. The package script should call that script, and the test should import the plan or call the script in dry-run/list mode instead of parsing package.json shell text.

[branarakic]

Addressed in 898d101. The package script now delegates to scripts/build-runtime-packages.mjs; its filters live as structured roots/exclusions in scripts/lib/runtime-build-plan.mjs, and the regression test imports that canonical plan directly instead of tokenizing package.json shell text.