♻️ refactor: own cross-runtime test infrastructure as @executablemd/test-support

[taras]

Why

packages/test-support was still published to the workspace as
@effectionx/bdd, but it has not been that package for a while. Upstream
@effectionx/bdd covers Node and Deno, and owns neither assertions nor process
launching. The local package drives Deno, Node, and Bun, ships a
cross-runtime expect, and is about to own the executable.md CLI launcher
arriving in #186. The borrowed name misrepresented what the code is and where
it comes from.

This separates repository-owned cross-runtime test infrastructure from the
upstream EffectionX BDD package, and gives the launcher in #186 a correctly
named home to land in. #186 is paused on this merging.

What changes

Before: tests imported @effectionx/bdd/node and @effectionx/bdd/expect,
resolving to a private local package that claimed the upstream identity and
declared only expect as a dependency.

After: tests import @executablemd/test-support/bdd and
@executablemd/test-support/expect. The package declares its real direct
dependencies — @effectionx/test-adapter, effection, and expect — at the
versions the root workspace already pins.

@effectionx/test-adapter is unchanged and still supplies the Effection scope
lifecycle that bdd.ts builds on. Only the BDD package identity is dropped.

How it works

Each runtime resolves the two subpaths by a different mechanism, so all three
had to move together:

Deno  → deno.json imports map        → ./packages/test-support/{bdd,expect}.ts
Node  → tsconfig.node.json paths     → ./packages/test-support/{bdd,expect}.ts
Bun   → workspace:* dep in node_modules → package.json "exports" {"./bdd","./expect"}

Bun resolves the package as a real workspace:* dependency and reads the
subpaths from the package's own exports map — bunfig.toml's
tsconfig-override does not provide module resolution.

What must stay true

• The package stays out of the lockstep release. It is private: true and
  carries no deno.json; scripts/build-npm.ts, the Generate block of
  scripts/gen-publish-workflow.md, and scripts/lib/bump-version.ts all skip
  workspace dirs without one. Verified: deno task gen:publish-workflow
  regenerates publish-packages.yml byte-identically (still 8 packages), and
  deno task check:jsr succeeds.
• Test semantics are untouched. bdd.ts and expect.ts have no changes —
  no edits to BDD lifecycle, runtime detection, assertions, sanitizers, or the
  public test API. Verified by the full Deno repository suite passing, and by
  the currently configured Node and Bun suites passing.

How to verify it

All checks run against the CI-pinned toolchains (Deno 2.9.1, Bun 1.3.14):

• deno task lint — 0 errors
• deno task check — 0 errors
• deno task test — 145 passed, 0 failed
• deno task check:jsr — Success Dry run complete
• pnpm install --frozen-lockfile — clean
• pnpm exec tsc --project tsconfig.node.json --noEmit — 0 errors
• pnpm test:node — 305 passed, 0 failed
• bun install — reports no changes; bun run test:bun — 272 passed, 0 failed
• deno task gen:publish-workflow — no drift

deno task test is the full repository suite. test:node and test:bun name
their test files explicitly, so they run a subset — deriving that scope is #144
and is not attempted here. What each proves is its own resolution path: a
missed deno.json, tsconfig.node.json, or exports entry fails that
runtime's tests with an unresolved-module error and nothing else. Every
migrated import is type-checked repository-wide by deno task check and
tsc --project tsconfig.node.json --noEmit.

git grep "@effectionx/bdd" returns nothing repository-wide.

Scope

Included

• Package rename, accurate dependency declarations, and ./bdd / ./expect
  export keys.
• 212 import lines across 106 files, including the lint-rule fixtures in
  scripts/tests/fixtures/ (excluded from lint and typecheck, but linted by the
  rule tests through the repository config).
• Resolution config: deno.json, tsconfig.node.json, root devDependency.
• Lockfiles: pnpm-lock.yaml, deno.lock, bun.lock.
• AGENTS.md rule 12 — records packages/test-support as the deliberate
  host-adapter boundary for tests, exempt from the no-runtime-detection rule,
  and notes that the Oxlint rule tracked by Route production host access through Env #156 carries the same path
  exemption. The module detects the runtime on purpose; that is how one BDD
  surface drives @std/testing/bdd, node:test, and bun:test.
• specs/executable-mdx-spec.md — the spec described bdd.ts as a
  "Deno-native BDD shim", which is wrong for a module driving three runtimes.
  Now "Cross-runtime Effection BDD adapter". Contract maintenance the rename
  forces.
• packages/durable-streams/specs/DECISIONS.md — DEC-004 named the old package.

Intentionally unchanged

• bdd.ts and expect.ts implementations.
• @effectionx/test-adapter — still an upstream dependency, unchanged.
• No launch.ts. ✅ test: launch the CLI through the host runtime #186 adds it after rebasing onto this.
• No root tsconfig.json — tested previously and it breaks deno check.

Generated or mechanical changes

• The 106 test and fixture files contain one mechanical substitution each and no
  intended behavior change. Reviewers can skim them.
• pnpm-lock.yaml, deno.lock, and bun.lock come from their own package
  managers. Each diff is confined to the rename and the newly declared
  dependencies — no unrelated re-resolution. bun.lock was generated with the
  CI-pinned Bun 1.3.14 rather than the local 1.3.10 so it converges with CI.

Scope confirmation

• Every changed file supports the purpose described above.
• Unrelated cleanup and formatting changes are excluded.
• Generated or mechanical changes are clearly identified.
• The description matches the final diff and test results.

[github-actions]

PR #188: ♻️ refactor: own cross-runtime test infrastructure as @executablemd/test-support

119 files, +250 / -234

Scope

🟡 484 lines changed. PRs under 400 receive more thorough review.

🟡 119 files changed. Are all changes related?

🟡 PR mixes config and source changes.

Structural

✅ No structural bloat detected.

Slop

✅ Slop indicators look low.

Static Analysis

✅ Oxlint found no issues.

Correctness

No extraneous code patterns detected.