Track the latest @rslint/core / @rstest/core: verify 0.9.0, join rstack-ecosystem-ci, un-pin E2E fixtures #40

Problem

The extension is developed and E2E-tested against a pinned toolchain that is already behind the registry, and nothing verifies it against new releases automatically.

• @rslint/core on npm is 0.9.0. The E2E fixture install root pins ^0.8.1 (packages/vscode/e2e/lint/fixtures/package.json) and packages/vscode/package.json declares ^0.8.0. The lint E2E slice has never run against 0.9.0.
• renovate.json5 puts @rslint/** / @rstest/** / rstack in the rstack toolchain group with schedule: at any time, but ignorePaths excludes packages/vscode/e2e/** on purpose ("bumping them is a manual, E2E-verified decision"). So the fixtures never move unless someone remembers. There is also no open Renovate PR for the 0.9.0 devDependency bump, which is worth checking.
• 0.8.2 → 0.9.0 changed two wire surfaces the lint worker sits on: CONFIG_DISCOVERY_PROTOCOL_VERSION 2 → 3 (plus a basePath field in flat-config entries) and the plugin-lint request field fix?: boolean → required collectFixes: boolean. Static reading says the worker survives both because it loads binary, config-loader and eslint-plugin host from one core root and passes the payloads through opaquely (packages/vscode/src/stacks/lint/worker/core.ts:98-153, ConfigTransactionAdapter.ts:61-149, PluginLintPool.ts:175-225). e2e/lint/suite-eslint-plugins/plugin-pool.test.ts:51-58 still builds a request with fix: false, which does not type-check against 0.9.0.

Before the standalone extensions were retired this was a non-issue: they lived in the rslint / rstest monorepos and moved with every release. Now every core release is a potential drift.

Proposal

1. Verify 0.9.0 now

• Bump e2e/lint/fixtures/package.json and the @rslint/core devDependency to 0.9.0.
• Change fix: false to collectFixes: false in plugin-pool.test.ts.
• Run pnpm test:e2e:lint and fix whatever falls out.

2. Join rstack-ecosystem-ci

Add this repo as a suite in https://github.com/rstackjs/rstack-ecosystem-ci so the extension's E2E runs against each stack's main / nightly / release on the daily schedule and on demand from a rstest or rslint PR.

• rstest: add tests/rstest/rstack-editor.ts alongside the existing rstack-cli.ts suite, running the rstest E2E slice (pnpm test:e2e:rstest) against the built @rstest/core.
• rslint: rstack-ecosystem-ci has no rslint stack today (stacks: rsbuild, rspack, rstest, rslib, rsdoctor, rspress). Either add one (three workflows + tests/rslint/) or, as a first step, run the lint slice under an existing stack with --release. Needs a decision with the eco-ci maintainers; a counterpart issue there may be needed.
• The suite must run a real VS Code (packages/vscode/e2e/run.mjs, VSCODE_CLI=1), so the eco-ci runner needs a display or xvfb. Check what rstack-cli.ts already does for headless runs.

3. Keep the fixtures on latest

• Decide whether the ignorePaths exclusion for packages/vscode/e2e/** still earns its keep once eco-ci covers the "does latest still work" question. Options: remove it and let the rstack toolchain group bump fixtures too (E2E on the Renovate PR is the verification), or keep the pin and rely on eco-ci to flag drift.
• Either way, widen the devDependency ranges so rangeStrategy: bump actually opens a PR for a new minor (^0.8.0 does not cover 0.9.0).
• SUPPORT_MATRIX in shared/versionCheck.ts is a floor, not a pin, and stays as is.