fix(runtime): bundle Deno canary 19bd3d8b as v2.8.0 bridge for tls_wrap panic

[stack72]

Summary

Bundles a pinned Deno canary commit (19bd3d8b) that contains the fix for the
tls_wrap Option::unwrap() panic in v2.7.12–v2.7.14
(denoland/deno#33713). The fix
landed on Deno main as df8d21c2 via
denoland/deno#33737 (merged
2026-05-01) and will ship in v2.8.0 in ~2 weeks. This bridge keeps swamp
shippable in the meantime — without it, every post-workflow datastore push
crashes with exit 134.

Lineage verified: 19bd3d8b is 83 commits ahead of fix commit df8d21c2,
0 commits behind. Strictly downstream.

Lab issues this addresses: swamp-club#213, swamp-club#219, swamp-club#224.
Also unblocks the swamp-club CI Deploy workflow, which has been failing on
every push to main since 2026-04-30 at the post-workflow datastore-push step.

Design

Single-file toggle (scripts/deno_canary.txt) with three priority tiers:

1. DENO_CANARY_SHA env var (CI ad-hoc override).
2. First non-blank, non-#-comment line of scripts/deno_canary.txt.
3. Null → falls through to the existing stable GitHub-releases path,
   bit-identical to before.

version.txt is stamped canary-<short-sha> (vs 2.7.14 for stable). The
distinct shape forces EmbeddedDenoRuntime to re-extract on canary→stable
swap, so no stale binary lurks on user machines after the bridge is removed.

Removal contract

All canary code is wrapped in // CANARY-BRIDGE markers at three sites in
scripts/download_deno.ts. The full back-out checklist lives in the header
of scripts/deno_canary.txt. When v2.8.0 ships:

1. rm scripts/deno_canary.txt scripts/download_deno_test.ts
2. Delete the two CANARY-BRIDGE blocks in scripts/download_deno.ts
3. `grep -rn CANARY-BRIDGE` returns zero matches
4. Bump system Deno to v2.8.0
5. Rebuild and republish swamp via the normal release flow

compile.ts, deno.json, and .github/workflows/release.yml are untouched.

Test Plan

• All 5 canary URLs HEAD'd 200 across the swamp build target matrix
  (linux-x86_64, linux-aarch64, darwin-x86_64, darwin-aarch64, windows-x86_64)
• deno run check / lint / fmt / test (5401 passed / 0 failed)
• Local aarch64-apple-darwin end-to-end: compile → run → bundled deno
  extracts to ~/.swamp/deno/, version marker = canary-19bd3d8b
• TLS panic repro (tls_writev_empty.ts) runs clean on canary;
  reproducibly panics on v2.7.14
• swamp-uat uat:cli on aarch64-apple-darwin (run twice for variance):
  canary 387 passed / 11 failed vs stable v2.7.14
  382 passed / 16 failed. Zero panic / tls_wrap / SIGABRT /
  unwrap signatures in either build
• Cross-target compile gated on this PR's CI matrix (covers the 4 targets
  not built locally)

Out of scope

• swamp-club#224 references two additional swamp-side bugs unrelated to this
  bridge: process-doesn't-exit-after-panic and stale-lock-loop. Separate fix,
  separate PR.
• swamp doctor audit UAT failures observed on this machine reproduce on
  stable too — pre-existing environmental issue, deferred.

🤖 Generated with Claude Code

[github-actions]

Code Review

Clean, well-scoped bridge fix. The temporary canary pin is properly isolated with consistent CANARY-BRIDGE markers at all three sites, a clear back-out checklist in scripts/deno_canary.txt, and a pure buildDownloadPlan function that's easy to test and reason about.

Blocking Issues

None.

Suggestions

1. Tests excluded from CI: scripts/download_deno_test.ts lives in scripts/ which is in the deno.json exclude list, so these tests won't run in deno run test. The PR acknowledges this and provides manual run instructions, and the real validation is the compile + smoke test — but worth noting that CI won't catch regressions in buildDownloadPlan if someone edits it before the bridge is removed.

2. No SHA format validation on DENO_CANARY_SHA env var: The env var is passed directly into URL construction without checking it's a valid hex string. Low risk since this is a developer build tool (a bad value just produces a 404 from fetch), but a simple /^[0-9a-f]{40}$/ guard in readCanarySha would fail fast with a clear message instead of a cryptic download error.

Overall: well-designed temporary bridge with minimal blast radius. The DownloadPlan value object cleanly separates URL construction from the download/extract pipeline, and the version-label distinction (canary-<short-sha> vs semver) correctly forces re-extraction on channel switches. LGTM.