Add JavaScript/TypeScript linting support

[ineedjet]

Problem

lint-shared.yml has no linter for JavaScript/TypeScript. detect-linters.py only recognizes the hook ids declared in .pre-commit-hooks.yaml (yamllint, pymarkdown, ruff, tombi, shellcheck, actionlint, rubocop, erb-lint, herb), and lint-shared.yml / setup-runtimes only wire up those same nine. A repo that's mostly/entirely TypeScript or JavaScript (e.g. a Vite + React app) gets a permanently green lint check that never actually inspects the source — it's silently skipped, not passing.

Hit this on intgame-ru/x52027 (Vite + TanStack Start + React + TypeScript): lint / lint is green on a PR where local tsc --noEmit reports a real type error and eslint . reports 30+ real issues, because the shared workflow doesn't know these file types exist.

Request

Add JS/TS support following the existing per-linter pattern:

• .pre-commit-hooks.yaml: new hook id(s), matched via identify tags. Confirmed via identify.tags_from_filename: .js/.mjs/.cjs → javascript, .jsx → jsx, .ts → ts, .tsx → tsx (four distinct tags, no single javascript-covers-all tag — worth deciding whether TS gets its own hook id or folds into one javascript/typescript hook with types_or).
• hooks/<linter>.sh
• .github/actions/lint-<linter>/action.yml, running against a canonical config/<linter>.*
• wire the new id into lint-shared.yml and .github/actions/setup-runtimes (the latter will need actions/setup-node, which none of the current linters require).

Linter options — feedback/preference welcome

1. ESLint (flat config) + typescript-eslint — what most TS/React repos already run locally (including ours). Big plugin ecosystem (react-hooks, react-refresh, jsx-a11y, etc.), so it composes well with framework-specific needs. Downside: a single canonical flat config is harder to make universally sensible across React/Vue/Node/plain-JS repos without per-repo overrides — less clean-cut than e.g. ruff.toml for Python.
2. Biome — single fast Rust binary, zero-config-friendly, bundles linting and formatting (could subsume/complement Prettier in one pass). Fits Baseline's "one canonical config, no setup" model more naturally. Downside: smaller rule/plugin surface than ESLint today (e.g. no direct react-hooks-equivalent parity, fewer framework-specific plugins), so it may not catch everything teams currently rely on ESLint for.

No strong opinion from our side on which one Baseline should standardize on — happy to help implement whichever direction you'd rather take, following the pattern above.