Runtime migration: record the Deno 2.9.8 findings as open decisions

The runtime-migration plans stay frozen, and findings that change another
plan's prerequisites go to README "Open decisions with an owner", which each
plan's step 0 reads. So the PR 01 status note moves out of its plan into a
row, and rows are added for PR 00b (deno install --allow-import), PR 15
(port.ts listing still has 4160 and a private isPortSafe) and the sanitizer
checks in PRs 15, 16, 23 and 31 (sanitizers are off by default on Deno 2.9
and the harness leaks when they are on). HANDOFF names 00a as in progress.

Author: cderv

dev-docs/runtime-migration/HANDOFF.md

@@ -46,7 +46,7 @@ These were throwaway and are recreated by the plans when needed:
 `REVIEW-2026-10-15.md` is the principal review of the first draft (13 structural findings, per-plan defects, the landing strategy, the decisions taken in its section 6).
 Every plan was then reworked against it: six new PRs (00a, 00b, 00c, 02b, 14b, 20b, 27b), PR 21 folded into 25, PR 07 and PR 39 rewritten and renamed, `SPIKES.md` added, `_TEMPLATE.md` vocabulary updated, `00-assessment.md` given an errata section.
 `README.md` carries the new table, dependency graph, conventions and baseline.
-The plans are now executable in the README order; PR 02 (#15135) and 02c (#15153) are merged, and the next to run are 00a, then 00b.
+The plans are now executable in the README order; PR 02 (#15135) and 02c (#15153) are merged; 00a is in progress as the Deno 2.9.8 security bump (#15152), and 00b runs next.
 
 ## Reconciliation pass (bucket B of `TRIAGE-2026-10-16.md`): done on 2026-10-16
 

dev-docs/runtime-migration/README.md

@@ -133,6 +133,10 @@ The rows below are the ones that still need a named person or an external answer
 | PR 18 Tasks 1–3 (from the #15119 fix, once `src/deno_ral/kv.ts` is on `main`) | `kv.ts` already exists (`openKv`, `getKv`, `kvOp`, `KvDamagedError`) and both caches go through it, so Task 1 extends the file instead of creating it and its "Module not found" RED step no longer holds. `openKeyValueStore` keeps the damage mapping: a damaged value reads as a miss with one warning, a damaged file fails with `KvDamagedError` naming the folder to delete, any other error is wrapped with the path. The `src` baseline drops by 5, not 7 (the two `Deno.openKv` calls are already in the layer). The `Deno.openKv` grep acceptance check covers `src` and `package` only, since three cache tests build damaged fixtures with `Deno.openKv` on purpose. The `kv.ts` row in `.claude/rules/typescript/deno-ral.md` exists: update it | coordinator | PR 18 step 0 |
 | PR 19 Task 1, PR 27b | both replace the whole body of `platform.ts`: keep the `v8Branch` export (`_TEMPLATE.md`, "`platform.ts`"); PR 27b computes it from `process.versions.v8` | coordinator | step 0 of each |
 | PR 30 | tagged `v8-<branch>/` directories are left behind like the untagged `.kv` files; remove `v8Branch` and its contract-test line together with its last consumer. What "damaged" means for the JSON index (unparsable or truncated file): keep the miss-with-warning versus fail-naming-the-folder split or not. The Deno KV damage tests (`tests/unit/kv-damage.test.ts` and the damaged-store cases in `sass-cache.test.ts` and `project-cache.test.ts`, from the #15119 fix) build real SQLite damage: they are replaced or deleted here, because PR 32 runs the full unit suite on Node, where neither `Deno.openKv` nor its damage exists, and "`sass-cache.test.ts` stays green" is restated accordingly | maintainer (damage semantics), coordinator (the rest) | PR 30 step 0 |
+| PR 00b, vendor script steps | Deno 2.9 rejects permission flags on a non-global `deno install` (denoland/deno#36489), and the vendor scripts keep going after a failed entrypoint, so `--allow-all` vendors nothing. Every `deno install` line the plan adds uses `--allow-import`, as the current vendor scripts do since #15152; its `deno run` and `deno bundle` lines keep `--allow-all` | executor | step 0 of PR 00b |
+| PR 01 | The `assert` → `with` half landed with #15152 (TypeScript 6 in Deno 2.9 rejects `assert`, TS2880), and it changed the IDE bundles: esbuild now wraps the JSON module as ESM (same data, same `.default`). Skip those edits and the "bundles unchanged" check; the PR keeps only the bslib ordering | executor | step 0 of PR 01 |
+| PR 15 Task 2 | The replacement `port.ts` listing has `4160, // sieve` and a private `isPortSafe`. Since #15152 the list has `4190` (the Fetch standard's bad port, which Deno 2.9's `fetch` refuses) and `isPortSafe` is exported for `tests/unit/core/port.test.ts`. Keep both; the test must still pass | executor | step 0 of PR 15 |
+| PRs 15, 16, 23 and 31, sanitizer checks | Deno 2.9 turns test sanitizers off by default and `tests/test.ts` passes none, and forcing them on fails every test with a harness leak (an open file and a timer, already present on Deno 2.7.14). The plans' "no sanitizer failures" checks and PR 31's "Leak guarantees" reference to Deno's sanitizers prove nothing until the harness leak is fixed and sanitizers are re-enabled | maintainer | before PR 15 runs |
 
 ## Shared rules and tables