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

@@ -125,6 +125,10 @@ mistakes before a human does.
 - **A skipped test fails the gate.** Never let a skip report green.
 - **Print a summary with numbers**, not just a verdict — counts of warnings, suppressions, and
   file-size violations. A suppression count that has grown is worth seeing even on a pass.
+- **Don't reimplement in the gate what a test can assert.** Checks like file-size limits
+  belong in the test suite where they travel with the repo and fail with a useful message;
+  the build script is the fallback for projects with no suite to hang them on. See
+  [`coding-dev.md` §4](skills-public/coding-dev.md).
 - Keep per-step logs in a known directory so a failure can be read after the fact.
 - **Never bypass a failed gate** by copying a binary or running the install step by hand. Fix
   the failing step; do not weaken the check to make it pass.