build(deps): bump @lumencast/runtime to 0.7.0

[ClodoCapeo]

What

Bumps @lumencast/runtime ^0.6.0 → ^0.7.0 (lockfile resolves 0.7.0; transitive @lumencast/protocol 0.6.0 → 0.7.0). Solar is the sole renderer / thin adapter over the runtime (ADR 007).

Breaking changes encountered & how adapted

1. Adapter API: no change. The runtime symbols Solar consumes (mount, MountOptions, LumencastError, LumencastStatus, RenderNode, RenderBundle) are byte-identical 0.6 → 0.7. src/mount.ts and src/types/index.ts are untouched; tsc -b green without edits.

2. patch-package retarget. The committed ADR 011 I7 keyframe-compositing patch (display:contents dead-box + translateX/Y → framer x/y mapping) is still not upstreamed in 0.7.0 — verified against the published dist. The patch remains necessary; regenerated against the 0.7.0 files (5 file diffs, same edits) as patches/@lumencast+runtime+0.7.0.patch; the obsolete 0.6.0 patch is removed. npm ci re-applies cleanly.

3. New deny-by-default asset host gate (behaviour change). 0.7.0 (LSML 1.2, ADR 002 #F — Bastion T1/T2) routes every image src through gateSrc() before the DOM: T2 admits only https: schemes, T1 requires the URL host in the bundle's assets.allowedHosts. A bundle with no allowlist has its <img> omitted entirely. tests/unit/render.test.tsx served http://x/logo.svg with no allowlist → no <img> under 0.7 → waitFor timeout. Adapted the test bundle to declare assets.allowedHosts: ["cdn.example"] and serve https://cdn.example/logo.svg; width/height/src assertions preserved. Legitimate runtime hardening, not a Solar regression.

Verification (real, executed)

Gate	Result
eslint --max-warnings 0	✅ pass
tsc -b (strict)	✅ pass
vitest run	✅ 37/37 pass
npm run build (lib + host + html)	✅ pass
npm ci (patch re-apply)	✅ pass
bundle-size budget	✅ broadcast 30 KiB gz / control 32 KiB gz (≤ 200 / 280)

Sensitive surface note (deps)

npm audit reports a high ws@8.20.0 advisory on the prod path — pre-existing, resolved identically on origin/main under 0.6.0 (the ^8.18.0 constraint is unchanged across the bump). This bump introduces zero new audit findings. Flagging per the deps-surface rule; not fixed here (out of scope — a ws fix would drift unrelated deps).

Render-headless surface (pillar 3 quality-gate, for a future amendment)

State of the bundle → PNG building blocks in 0.7.0:

• BroadcastMode — exists (modes/broadcast.tsx, "pure scene render, no UI chrome"), but internal: not exported from the package index.d.ts. Signature BroadcastMode(): JSX.Element, reads its data from React context.
• LumencastRuntimeProvider — exists (overlay/runtime-context.tsx), internal. Render is driven by a LumencastRuntime context value { mode, store, bundle, status, sendInput }. This is the seam a headless renderer would feed: a bundle + a populated store + status → <BroadcastMode/> under the provider, renderable with renderToStaticMarkup.
• compileBundle — does not exist in 0.7.0 (no LSML→bundle compiler in the runtime; bundle.ts notes a "forthcoming @lumencast/compiler"). A headless path consumes an already-compiled RenderBundle.
• status:"live" without a WS — no public injection point. mount() always opens a WS; status derives from the transport ConnectionStatus. Headless bundle → PNG would need either a new runtime entry that renders BroadcastMode from a static bundle+state (bypassing the WS) or these internals promoted to the public surface.

Net for pillar 3: 0.7 neither facilitates nor blocks headless render — the pieces (BroadcastMode, provider, RenderBundle) are present and clean but all internal, and there is no no-WS static-render entry. An amendment would need a runtime change (new public export or headless entry), i.e. a Lumencast-side ADR — not a Solar-side change.

Refs #24

🤖 Generated with Claude Code

[ClodoCapeo]

Update — CI now fully green (5/5).

The Dependency audit (npm audit --omit=dev --audit-level=high) job initially failed on a high ws advisory (ws 8.0.0-8.20.1: GHSA-58qx-3vcg-4xpx + GHSA-96hv-2xvq-fx4p), pulled transitively on the prod path via @lumencast/protocol/@lumencast/runtime (both pin ws ^8.18.0).

This advisory was published after main's last green run (2026-06-13) and resolves identically under 0.6.0 — it is environmental, not introduced by the runtime 0.7.0 bump. Fixed with a resolution-only bump to the patched ws@8.21.0 (within the existing ^8.18.0 range; no other deps drift). Prod npm audit now reports 0 vulnerabilities.

Remaining npm audit findings (vite/esbuild, 2 high) are dev-only, excluded by --omit=dev, and pre-exist on main — out of scope here.