fix(coding-dev): prefer a test over the build script for size limits

A shell check only runs where that script runs. A test travels with the repo,
needs no extra tooling, and fails with a message naming the offending files.
Enforcement is now a preference order: native linter rule > test > build
script as fallback, with a worked example and a note on why a per-compile
build hook usually is not worth the incremental-build cost.

Propagated per language: rust (clippy has no file-length lint -> workspace
root test), js-typescript (ESLint max-lines covers both natively, no test
needed), go/python/csharp (linter for functions, test for files), bash (don't
reimplement in the gate what a test can assert).

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

code-languages/js-typescript.md

@@ -141,7 +141,8 @@ Attach an `AbortController` to every long-lived `fetch` and abort it in cleanup.
   a new formatter or lint config into a project that already has one.
 - **One file until it earns a split** — around 250 lines for a self-contained plugin/feature,
   or when a second file is genuinely reusable (`utils.ts`, `types.ts`, `components/`).
-  Hard limits from the general rules still apply.
+  Hard limits from the general rules still apply: ESLint's `max-lines` and
+  `max-lines-per-function` cover both natively, so prefer those over a separate test here.
 
 ---