fix(coding-dev): scoped suppressions, contribution-dependent precedence

- suppressions: prefer the narrowest scope that covers the problem (line,
  function, module) with a reason comment; a project-wide disable silences
  the rule in code nobody has written yet. Always name the specific rule.
  Propagated to rust (#[allow]), csharp (#pragma/SuppressMessage).
- precedence: a project's own rules win only when contributing upstream.
  For local/private work these rules win, adopting only the project's
  load-bearing conventions.
- type checking must pass with zero errors *or warnings*.

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

code-languages/csharp-dotnet.md

@@ -37,8 +37,11 @@ dotnet build MySolution.sln -warnaserror
 - **Nullable warnings are real bugs.** Never silence one with `!` (null-forgiving) — narrow
   the type or fix the contract. `!` is an assertion, and an assertion you cannot prove is a
   future `NullReferenceException`.
-- Never blanket-disable an analyzer. If a rule is genuinely wrong for the codebase, configure
-  it once in `.editorconfig` with a comment.
+- Never blanket-disable an analyzer. When a rule is genuinely wrong for a piece of code,
+  scope the suppression to it — `#pragma warning disable CA1822` around the smallest region
+  that needs it (with a matching `restore`), or a targeted `[SuppressMessage]` attribute —
+  and always with a `Justification` / comment saying why. An `.editorconfig` entry turns the
+  rule off for every file it covers; use it only when the rule is wrong codebase-wide.
 
 ---