chore(lint): hold tests to their own max-lines ceiling (#1306)

* chore(lint): hold tests to their own max-lines ceiling

The flat 400-line cap treated a spec like a component. A spec is a flat
list of independent cases, so hitting the cap there produces arbitrary
`-2.spec.ts` splits and hides coverage instead of surfacing design debt —
65 of the 138 files over the limit were tests.

Production code keeps 400. Tests (`**/*.spec.ts`, `**/*.e2e.ts`, and
everything under `apps/*-e2e/**`) get 1200. Blank lines and comments no
longer count, so a docblock can't be the reason a file must be split.

Both limits now live in tools/eslint/max-lines-config.mjs, imported by
eslint.config.mjs and the baseline generator alike. The generator decides
who belongs on the list by running ESLint's own max-lines rule instead of
counting lines itself — a private reimplementation would disagree with the
rule the moment either side changed (a `//` inside a template literal is
enough) and yield a baseline that turns CI red while looking correct.

The baseline drops 126 -> 68 entries with nothing added, and six now-dead
`eslint-disable max-lines` directives are removed. A new eslint-tools test
asserts the committed baseline still matches what the generator produces,
so a stale entry or a forgotten regeneration fails CI.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* chore(lint): classify eslint-tools in the coverage policy

A project with a `test` target must be assigned a coverage tier, so
adding eslint-tools broke `coverage:policy:check` before the unit suite
even ran. Tier B alongside packaging and release-tools: these are Node
tests over lint tooling, and a coverage percentage across a generated
list would not mean anything.

CI runs Tier B/C through its own `--run-non-tier-a` step, so the
baseline-consistency test executes there rather than being skipped.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

docs/architecture/validation-map.md

@@ -34,9 +34,12 @@ The CI workflow (`.github/workflows/ci.yml`) lints affected projects on PRs
 (`nx affected`) and every project on master pushes.
 This enforces `@nx/enforce-module-boundaries` (scope/domain/type tag
 constraints), the legacy bare-alias ban, and the `max-lines` file-size rule
-(hard maximum 400 lines per TypeScript file). Files that predate the
-`max-lines` rule are baselined in `tools/eslint/max-lines-baseline.mjs`; after
-splitting a baselined file below the limit, regenerate the list with
+(hard maximum 400 lines for production TypeScript, 1200 for tests; blank lines
+and comments are not counted). The limits live in
+`tools/eslint/max-lines-config.mjs`, which both `eslint.config.mjs` and the
+generator import. Files that predate the `max-lines` rule are baselined in
+`tools/eslint/max-lines-baseline.mjs`; after splitting a baselined file below
+the limit, regenerate the list with
 `node tools/eslint/generate-max-lines-baseline.mjs`. Never add new files to
 the baseline.