Reintroduce accessibility linting (replacement for eslint-plugin-jsx-a11y)

[plx]

Context

The ESLint 10 / TypeScript 6 upgrade (PR #41) removed eslint-plugin-jsx-a11y from devDependencies and deleted the ...astro.configs[\"jsx-a11y-strict\"].rules spread in eslint.config.js.

That removal was a no-op at runtime: in eslint-plugin-astro@1.7.0, configs[\"jsx-a11y-strict\"] returns a Linter.Config[] (array), so .rules was undefined and the object spread was silently inert. So zero a11y rules were actually enforced before, and zero are enforced now. See .context/plans/lint-ts-track-step-1-of-the-major-version-migratio.md for the full analysis.

Even so, CLAUDE.md lists "reasonable accessibility support" as an explicit goal for this site, and we should restore real accessibility linting rather than leave it silently absent.

Blockers

eslint-plugin-jsx-a11y@6.10.2 peer-caps at eslint ^9. Upstream PRs adding ESLint 10 support are open but unmerged as of 2026-04-23:

• [New] Add ESLint 10 support jsx-eslint/eslint-plugin-jsx-a11y#1081
• [New] eslint 10 support jsx-eslint/eslint-plugin-jsx-a11y#1079

Acceptance criteria

Reintroduce accessibility linting such that:

1. An ESLint-10-compatible a11y plugin is wired into eslint.config.js (either eslint-plugin-jsx-a11y once an ESLint-10-compatible release ships, or an equivalent plugin for .astro files).
2. The config correctly consumes the preset — i.e. rules are actually applied, not swallowed by an object-spread on an array. Verify by deliberately breaking an a11y rule (e.g. an <img> missing alt) and confirming just lint flags it.
3. just lint and just validate still pass on a clean tree.
4. The risks/watch-items note in the migration plan is updated to mark this resolved.

Notes

Scope is both .tsx/.jsx (minimal today — one React file) and .astro files. For .astro, the fix likely involves composing the array-shaped preset from eslint-plugin-astro correctly rather than spreading its .rules.