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/rust.md

@@ -75,6 +75,10 @@ workspace = true
 - **Re-test every `#[allow]` periodically.** If removing one produces no warning, delete it.
 - `too_many_lines` is the mechanical enforcement of the 100-line function limit. A function
   that trips it wants extracting, not an allow.
+- Clippy has **no file-length lint**, so the 1000-line file limit belongs in a test — see
+  [`coding-dev.md` §4](skills-public/coding-dev.md) for the pattern. Put it in the workspace
+  root's `tests/` so one test covers every member crate, walking `src/` plus each
+  `crates/*/src`. `cargo test --workspace` then enforces it for free.
 
 ---