chore(toolchain): align Aspire-core pins to 13.4.6 (CI + OpenHands + scaffold)

[rickylabs]

Summary

Aligns Aspire-core pins to the current stable 13.4.6 across CI, OpenHands bootstrap toolchain, scaffold constants, generated aspire.config.json expectations, and docs examples. Goal B is researched and deferred because the current Aspire 13.4 docs still say CommunityToolkit Deno/SQLite hosting APIs are not available for TypeScript AppHost in the required form.

Scope

• Archetype / area: Archetype 6 CLI/tooling, Aspire scaffold/toolchain
• Run dir: .llm/tmp/run/chore-align-aspire-13.4.6--impl/

Slices

• Aspire-core pin alignment — 6804418f
• Harness commit record — 0bc452cb

Version Matrix

Before:

• .github/toolchain.env: Aspire CLI 13.4.0, Aspire SDK 13.4.4
• GitHub E2E workflow Aspire CLI pins: 13.4.4
• Scaffold SDK: 13.4.4
• Scaffold Aspire.Hosting.PostgreSQL/MySql/SqlServer/Redis: 13.4.4

After:

• .github/toolchain.env: Aspire CLI 13.4.6, Aspire SDK 13.4.6
• GitHub E2E workflow Aspire CLI pins: 13.4.6
• Scaffold SDK: 13.4.6
• Scaffold Aspire.Hosting.PostgreSQL/MySql/SqlServer/Redis: 13.4.6

CommunityToolkit pins remain on their separate line:

• SCAFFOLD_VERSIONS.ASPIRE_HOSTING_DENO: 13.4.0
• SCAFFOLD_VERSIONS.ASPIRE_HOSTING_SQLITE: 13.4.0
• SCAFFOLD_COMMUNITY_TOOLKIT.VERSION: unchanged pending follow-up

Sweep Result

• rtk grep '13\.4\.4': zero matches.
• rtk grep '13\.4\.0': two intentional matches, both CommunityToolkit Deno/SQLite constants in scaffold-versions.ts.

Goal-B Verdict

Deferred. aspire docs get deno-integration says TypeScript AppHost support for CommunityToolkit.Aspire.Hosting.Deno is not yet available and it does not expose addDenoApp/addDenoTask in the TypeScript SDK. SQLite docs likewise say SQLite hosting is C#-only for AppHost APIs and TypeScript should use builder.addConnectionString(...) with a parameter. A debt entry was added for a dedicated follow-up slice.

Validation

• deno run --allow-read --allow-run .llm/tools/run-deno-check.ts --root packages/cli --ext ts,tsx — pass, 524 files selected, 0 diagnostics.
• deno lint --no-config packages/cli/src/kernel/constants/scaffold/scaffold-versions.ts packages/cli/src/kernel/constants/scaffold/scaffold-aspire.ts packages/cli/src/kernel/templates/aspire/generate-aspire-config_test.ts — pass, checked 3 touched CLI TS files.
• deno test --allow-all packages/cli/src/kernel/templates/aspire/generate-aspire-config_test.ts packages/cli/src/kernel/constants/version-drift_test.ts — pass, 2 tests / 2 steps.
• deno task check:scaffold-versions — pass, 10 scaffold pins stable.
• deno task e2e:cli run scaffold.runtime --cleanup --format pretty — failed twice in native WSL worktree at database.init, raw exit code 1, counts passed=10 failed=1. Both failures were Aspire fixed-port bind failures on https://127.0.0.1:18891; cleanup ran, aspire ps returned [], and Linux ss showed no WSL listener after cleanup. The generated E2E project did restore Aspire SDK/package 13.4.6 before the bind failure.

Drift / Debt

• Goal B deferred with a new .llm/harness/debt/arch-debt.md entry.
• Final runtime E2E is not green in this environment because of the fixed-port bind failure above; evidence is recorded in worklog.md and drift.md.

[rickylabs]

✅ scaffold.runtime e2e GREEN — passed=47 failed=0 (exit 0)

The two earlier reds were not the version bump — they were the #138 fixed-port collision: a concurrent Windows eye-test Aspire instance held 127.0.0.1:18891 via WSL2 localhost-forwarding during this slice's e2e. That instance is gone, ports are free, and a clean re-run from the native worktree passes end-to-end:

> database.init             PASSED 46843ms   ← failed twice before (18891 bind); now green
> runtime.aspire-restore    PASSED  4790ms   ← restores the generated Aspire 13.4.6 SDK
> runtime.aspire-start      PASSED 15992ms
> runtime.wait.postgres     PASSED
> runtime.wait.garnet       PASSED
> runtime.wait.{workers,sagas,triggers,auth} … all PASSED
> behavior.* (29 probes)    all PASSED
> cleanup.aspire-stop       PASSED
Summary: passed=47 failed=0

This is the proof for the version bump: the generated project restores Aspire 13.4.6 and the full distributed runtime comes up healthy.

Verdict

• Goal A (Aspire-core → 13.4.6): complete. Clean sweep — zero 13.4.4 remain; the only 13.4.0 left are the intentional CommunityToolkit Deno/SQLite constants (Goal B's subject). Pins aligned across toolchain.env, the three e2e CI workflows (incl. the extra e2e-cli-prod-local.yml), scaffold-versions/aspire constants, the config-generator test, and the two affected docs.
• Goal B (CommunityToolkit Deno/SQLite re-enable): correctly deferred. aspire docs/integration search confirm the CommunityToolkit Deno hosting still exposes no addDenoApp/addDenoTask in the TypeScript AppHost SDK and SQLite hosting is C#-only — so Aspire 13.4 does not fix the TS-AppHost path. Workaround kept; deferral recorded in arch-debt.md.
• Scoped check/lint/fmt on packages/cli clean; affected unit tests updated to 13.4.6 and passing.

Merging: mechanical version-string alignment, fully proven by the canonical 47/47 merge-readiness e2e.