chore: add ESLint to enforce the code quality standards automatically

Note: this is an in-house item already being handled by the maintainer - not open for contribution. Filed for tracking only.

Why

The project has no linter. Dev dependencies today are @types/better-sqlite3, @types/jest, @types/node, jest, ts-jest, tsx and typescript. Style rules in the code quality standards are therefore enforced by review alone, which does not scale with outside contributions.

Prettier (#446) does not close this gap. Prettier reprints the AST with consistent whitespace and never changes code structure. Verified with Prettier 3.9.6:

// input
if (!value) return "none";
// after prettier: unchanged
if (!value) return "none";

There is no brace or curly option in Prettier at all, and this is deliberate: adding braces changes code rather than formatting it. Worse, when the line exceeds printWidth, Prettier wraps it without braces:

if (a === "x" && b === "y" && c === "z" && a.length > 10 && b.length > 20)
  return "a very long return value here indeed";

which now looks like a block but is not one. Adding a second statement at that indent runs it unconditionally.

What to do

Add ESLint with typescript-eslint, starting with a deliberately small rule set rather than a large preset:

• curly: ["error", "all"] - the rule that motivated this. Auto-fixable, and it closes #1089 permanently instead of once.
• eqeqeq
• no-unused-vars via @typescript-eslint/no-unused-vars
• no-nested-ternary

Add lint and lint:fix scripts, and a lint step in .github/workflows/ci.yml.

Sequencing

1. SPDX branch merges first.
2. Prettier (#446) lands next, while nothing else is in flight.
3. ESLint after that, configured with eslint-config-prettier so the two do not fight over formatting.

Do not bundle these. Prettier is a whole-codebase reformat and ESLint is a behaviour-adjacent auto-fix; keeping them in separate commits keeps git blame and review usable.

Scope discipline

Start narrow. A large preset on an existing 12,000-line codebase produces hundreds of violations and the temptation is to bulk-disable rules, which leaves the linter theatre rather than enforcement. Each rule added should be one whose violations we are actually willing to fix.

Run --fix and the full test suite in the same commit, and confirm the test count is unchanged. Auto-fixes should be mechanical, but no-unused-vars in particular can surface genuinely dead code that deserves a look rather than a deletion.

Closes the enforcement half of #420; #1089 is superseded by the curly rule.