deltic runtime convergence: webcrypto-deltic now carries its own runtime from raw github (pre-58b2404), invisible to the pin-drift gate

[lann]

Found while gating #47 (2026-08-11): the webcrypto sibling republished @polymorph/webcrypto-deltic@0.0.0 importing the deltic runtime from https://raw.githubusercontent.com/lann/deltic/pre-58b2404/runtime/... URLs rather than depending on jsr:@deltic/runtime. Two consequences:

1. Two deltic runtime copies in one module graph. This repository's embedder pins jsr:@deltic/runtime@0.1.0-pre.ga67ee83; the webcrypto host module's closure now carries pre-58b2404 internally. The endpoint exam passes against the mixed graph (the webcrypto seam is exercised heavily by the ed25519 identity path), so no observable break today — but this is exactly the double-runtime shape (WitError identity, plan-format skew) the packaged-translator work (Consume deltic from JSR: packaged translator, no fetch step #45/Converge .deps pins on the JSR-consuming siblings; gate module identity on the resolved graph #46) was ruling out.

2. The pin-drift gate is blind to it. exam-deltic's guard asserts every jsr:@deltic/* pin across the deno.jsons names the same prerelease; a runtime arriving over raw-github URLs never matches that grep. The gate that was supposed to fail loudly on runtime skew only fired indirectly, through --frozen lockfile staleness (Refresh deno.lock for the webcrypto-deltic republish #50).

Options, not mutually exclusive:

• Converge forward: move this repo's pins to the sibling's deltic version once a matching jsr:@deltic/* prerelease exists (the raw-URL import suggests pre-58b2404 is not on JSR yet).
• Ask the sibling to keep its published module depending on jsr:@deltic/runtime so one resolver-level pin governs the whole graph.
• Extend the drift guard to also scan the resolved lockfile for non-JSR deltic runtime sources and fail on version mismatch with the JSR pin.

#50 refreshes the lockfile to unbreak CI without deciding any of this.

[lann]

Closing as a mis-diagnosis (see #50's retraction). Corrected record:

• No JSR republish happened; @polymorph/webcrypto-deltic is not on JSR — it is the local .deps/webcrypto link. The raw-URL runtime imports were served by MY stale .deps/webcrypto checkout, cloned from a pre-Converge .deps pins on the JSR-consuming siblings; gate module identity on the resolved graph #46 branch; Converge .deps pins on the JSR-consuming siblings; gate module identity on the resolved graph #46 had already moved WEBCRYPTO_PIN to the JSR-consuming revision (a0c924d, js/deltic importing jsr:@deltic/runtime@0.1.0-pre.ga67ee83).
• The pin-drift gate is NOT blind: scripts/deltic-identity-gate.ts scans the resolved graph and rejected the raw-URL modules precisely as designed. Both gates (frozen install, identity) fired correctly.
• No residual version split exists at the converged pins: all three sibling checkouts' deltic modules import jsr:@deltic/runtime@0.1.0-pre.ga67ee83 at their pinned revisions.

The only genuine lesson: after pulling a branch that bumps .deps pins, re-run scripts/setup.sh — a stale checkout fails the deltic gates in ways that look like registry/sibling motion. That is working-as-designed fail-loud behavior, not a defect.