Add ESLint CI workflow with baseline (mirrors PHPStan setup)

[limad]

Summary

Adds a CI ESLint check for core/js/ and desktop/js/ with a baseline mechanism that mirrors the existing PHPStan workflow (per @kwizer15's suggestion in #3297). Catches actual bugs (no-const-assign, no-redeclare, no-unreachable, etc.) without enforcing style rules like no-var or prefer-const yet.

What's added

File	Role
.eslintrc.json	Bug-only ESLint rules (no-const-assign, no-redeclare, no-dupe-keys, no-unreachable, etc.)
eslint-baseline.json	Snapshot of the 175 currently-failing {file, ruleId, message} tuples — line numbers excluded so the baseline survives cosmetic line shifts
.github/scripts/eslint-baseline-check.js	Runs ESLint, diffs against baseline, fails only on NEW tuples
.github/workflows/eslint.yml	Runs the check on PRs and on push to develop. Includes an auto-update job that regenerates the baseline and opens a PR when fixes are merged (same pattern as update-phpstan-baseline)
package.json + package-lock.json	ESLint dependency only — no runtime impact

Why baseline-based

Upstream core/js/ + desktop/js/ currently emit ~175 ESLint errors (mostly no-redeclare from var X re-declarations across nested blocks, plus a few no-unreachable). A non-baseline approach would either:

• fail CI permanently until everything is fixed (blocks all PRs), or
• weaken rules so much that real bugs slip through.

The baseline tolerates existing issues, prevents new ones, and welcomes fixes (when a violation disappears, the auto-update job removes it from the baseline on merge).

Style rules deferred

no-var and prefer-const are intentionally not enabled in this PR — they would dominate the noise. They can be re-enabled in a follow-up once the migration from var to const/let (PRs C-F) lands.

Local usage

npm install
npm run lint           # raw ESLint output
npm run lint:check     # baseline-aware check (same as CI)
npm run lint:baseline  # regenerate baseline after fixes

Test plan

• CI runs eslint job on this PR — expect green (current = baseline = 175)
• Verify that introducing a new violation in any JS file fails CI locally with npm run lint:check
• After merge, verify the update-baseline job triggers on push to develop

Part of the split following #3297 discussion. Standalone — does not touch any existing JS files.