chore: update Lynx toolchain to 3.9 release line

[KealanAU]

Summary

Bumps the Lynx toolchain to the 3.9 release line and fixes the small amount of breakage from the upgrade.

• Most of the diff is mechanical: dependency versions, example package bumps, and the lockfile.
• Hand-edited fixes cover the testing-environment 0.2 API, __SetID typing, docs build deps, and one stricter SFC compiler issue.
• Adds the release changeset.

Review notes

Worth reviewing first:

• examples/event-modifiers/src/PreventDemo.vue — reworks invalid escaped markup into a live @tap / @tap.prevent demo.
• packages/vue-lynx/main-thread/src/ops-apply.ts — uses ?? null for the newer __SetID type.
• packages/testing-library/* and packages/upstream-tests/* — updates for @lynx-js/testing-environment 0.2.
• website/package.json — restores docs build resolution with an explicit @lynx-js/lynx-core dependency.

Safe to skim:

• pnpm-lock.yaml
• examples/*/package.json version bumps
• generated/API-doc ignore entries

Verification

• pnpm install --frozen-lockfile
• Build passes
• Tests green: testing-library 104, upstream 854, dom 59, local 23
• 25/25 examples build
• Rspress docs build passes
• changeset status reports a vue-lynx patch

Follow-up: evaluate upstream @lynx-js/react/testing-library as a possible replacement for the custom testing-library package.

[vercel]

@KealanAU is attempting to deploy a commit to the huxpro's projects Team on Vercel.

A member of the Team first needs to authorize it.

[Huxpro]

Looks fine from my side.

Two things I would still like the PR description or a follow-up comment to clarify:

• why the two newly introduced dev dependency bumps are required as part of the 3.8.1 line update
• why @lynx-js/lynx-core is intentionally exact-pinned here instead of following the repo's usual range policy

[KealanAU]

Thanks @Huxpro.

• @microsoft/api-extractor: optional peer of @rslib/core, so pnpm won't auto-install it. The plugin's dts: { bundle: true } is the only thing that needs it — required unless we ship unbundled declarations.
• vue: dropped it. It was pulled in by a DefineComponent import and a declare module "vue" global-components augmentation; both retargeted to @vue/runtime-core, which we already depend on and which declares GlobalComponents. Keeps us on the granular @vue/* packages.
• @lynx-js/lynx-core exact pin: checked web-core's manifest to answer this properly — it declares @lynx-js/lynx-core as an optional peer pinned to exactly 0.1.3, not a range. The website entry only exists to surface that peer's /web subpath after the lockfile re-resolution pruned it, so it has to match web-core's pinned instance; ^0.1.3 could float to a future 0.1.4 and desync (peer mismatch + duplicate copy). So this isn't a deviation from the range policy for its own sake — the version is fixed upstream, not ours to widen. I'd keep it pinned for that reason, but it's a docs-only dep, so if you'd still prefer the range for consistency, say the word and I'll switch.

[Huxpro]

Following up on the earlier approval — the hand-edited fixes all look correct: the __SetID(… ?? null) change matches Lynx types 3.9, and the testing-environment 0.2 migration (new LynxTestingEnv({ window }) / env.env.window) is applied consistently across both packages. One thing to reconcile before merge: your reply noted vue was dropped in favor of @vue/runtime-core, but the current branch head still adds "vue": "^3.5.0" to packages/vue-lynx/package.json devDependencies — please push that removal so the branch matches the stated resolution. The failing status is just the Vercel deploy-authorization gate for the fork, not CI; a maintainer will need to authorize that deploy.

---

Generated by Claude Code

[KealanAU]

Pushed the vue devDep removal (1b0df22) — the branch now matches the stated @vue/runtime-core resolution.

While reconciling that, I fixed the mislabel you'd already flagged: the pinned surface is @lynx-js/types 3.9.0, so this is really the 3.9 line, not 3.8.1 (the __SetID(… ?? null) change being a 3.9 types change, as you noted). Updated the changeset text and the PR title to 3.9. Left the branch name as-is since it's deleted on merge.

No docs needed updating — the only version reference is the generated PluginVueLynxOptions API doc, which already reads engine >= 3.9.0.

Re Vercel: understood, that's the fork deploy-authorization gate rather than CI — nothing outstanding on my end.

[KealanAU]

Fixed the CI failures the upstream merge introduced (Test - Pipeline / Test - Vue Upstream).

• The merged-in upstream tests (ifr.test.ts, page-root-dom.spec.ts, plus a type annotation in lynx-runtime-dom-bridge.ts) still used the pre-0.2 env.jsdom.window accessor.
• @lynx-js/testing-environment 0.2 renamed that to env.env.window, which the rest of this branch already migrated to — so the new files threw Cannot read properties of undefined (reading 'window').
• Renamed the accessor to .env in those files; testing-library (198) and dom (60) suites are green again locally.

[KealanAU]

Follow-up: audited the 3.9 bumps for completeness and fixed two gaps (commit b922d95).

@lynx-js/lynx-core version note was stale. The changeset said the website pins it to 0.1.3, but the actual (correct) pin is 0.1.4 — that's what web-core@0.22.1 resolves its optional lynx-core peer to in the current lockfile. The 0.1.3 copies still in the tree belong to template-webpack-plugin@0.11.2's peer, a separate consumer, not the website's. Corrected the changeset prose to 0.1.4.

packages/ifr-bench was never bumped. It was still on @lynx-js/testing-environment ^0.1.2 (old 0.1 API). It's a private, script-only bench tool not covered by CI, so it didn't fail anything — but it's off the 3.9 line. Bumped it to ^0.2.1 and migrated the three new LynxTestingEnv(jsdom) call sites to the 0.2 shape new LynxTestingEnv({ window: jsdom.window }). Its correctness oracle (pnpm --filter vue-lynx-ifr-bench check) passes all 21 variants on the new API; frozen install passes and the main suites stay green.

Left ifr-bench/rl-probe alone. It's a grandchild dir (packages/ifr-bench/rl-probe), so packages/* doesn't include it — outside the workspace, lockfile, and CI. It's a ReactLynx comparison baseline whose @lynx-js/react version is arguably meant to be independent of the vue-lynx toolchain, and I can't validate a bump to a builder that isn't installed here. Happy to bump it too if you'd prefer strict consistency.

[Huxpro]

Thanks for putting this upgrade together. We plan to merge it after the Vapor release.

The intended release sequence is:

1. Release Vapor as vue-lynx@0.6.0 on the current Lynx toolchain.
2. Merge this toolchain upgrade and release it as vue-lynx@0.6.1.

This keeps the Vapor release independent from the toolchain bump, so users on both the current and upgraded Lynx toolchain lines can adopt Vapor without the toolchain upgrade being a prerequisite. We should also change this PR’s Changeset from minor to patch before merging so it produces 0.6.1 rather than 0.7.0.