v0.6.1 — the deck runtime baked in one site's storage key

A defect in 0.6.0, and it had no fixed point.

What was wrong

blocks/deck-runtime.js carried:

var LANG_KEY = "rb-lang";

That is blust.ch's own key — a substituted value, captured when the block was extracted from
blust.ch's deck. blocks/lang.js, the standalone language fence, correctly carries the
{{langKey}} template; the runtime carried what that template had already become on one
particular page. And the deck runtime fence declared no params, so it had no way to substitute
anything.

The consequence was a loop

1. Syncing deck runtime writes rb-lang into the page.
2. The nested language fence's own pass rewrites it to the site's key.
3. deck runtime's content no longer matches what the package emits, so design:check reports it
   as differing.
4. The next sync starts over.

companygraph.io sat exactly there: functionally correct at cg-lang — which its own storageKeys
check requires — with design:check permanently red. guestgraph.io would have been the same.

blust.ch passed by coincidence. Its key is the one that was baked in.

The fix

The block carries {{langKey}}, byte-identical to what blocks/lang.js carries, and the fence
declares params: ["langKey"] the way "language" does. Both passes emit the same bytes, so the
sync settles.

runtime → v2. Sites on 0.6.0 re-sync; there is no action beyond npm run design.

Two tests, and the second is the one that matters

• No literal may follow LANG_KEY = " in the block. Fails when rb-lang is put back.
• A fixed point, driven through bin/design.mjs: check → sync → check → sync → check,
  asserting the second sync writes nothing and the check after it is still clean.

That second test is the property that was missing. The first verification of this area checked that
the value came out right and never checked that the result was stable — which is the entire
difference between a working substitution and a loop.

120 tests.