fix(rules): stop prescribing JS casing for every language in common/

`common/coding-style.md` has no `paths:` frontmatter, so it is loaded for every
source file regardless of language. Its Naming Conventions section nevertheless
prescribed `camelCase` for variables and functions, which is not idiomatic for
several languages the package supports: `python/coding-style.md` mandates PEP 8
(`snake_case`) and `rust/coding-style.md` mandates `snake_case` for functions,
methods and variables. Both carry `paths:` frontmatter, so for a .py or .rs file
the agent is handed two opposite naming rules in the same context. README.md does
state that language-specific rules take precedence, but that statement lives in
the README rather than in the rule files the agent actually receives.

Replace the casing list with the canonical `**Language note**` marker documented
in rules/README.md, and keep only what is genuinely language-independent:
descriptive names, boolean prefixes, and constants and types being visually
distinct from values, and only where the language draws that distinction at all.
The per-language examples name only languages whose own coding-style.md actually
states a casing standard.

Drop the "Custom hooks: camelCase with a use prefix" line and link to
react/coding-style.md instead — it is React-specific and documented there both as
the `useCamelCase` symbol rule and as the eslint-plugin-react-hooks enforcement
note. react/coding-style.md is path-scoped, so a hook colocated outside
`components/**` or `hooks/**` no longer receives the rule; see the PR description.

Fixes #2830

rules/common/coding-style.md

@@ -59,11 +59,19 @@ ALWAYS validate at system boundaries:
 
 ## Naming Conventions
 
-- Variables and functions: `camelCase` with descriptive names
-- Booleans: prefer `is`, `has`, `should`, or `can` prefixes
-- Interfaces, types, and components: `PascalCase`
-- Constants: `UPPER_SNAKE_CASE`
-- Custom hooks: `camelCase` with a `use` prefix
+> **Language note**: This rule may be overridden by language-specific rules for
+> languages where this pattern is not idiomatic. Casing in particular belongs to
+> the language file — e.g. PEP 8 for Python, `snake_case` for Rust, `camelCase`
+> for Java and Kotlin. React hook naming lives in
+> [react/coding-style.md](../react/coding-style.md).
+
+Language-independent:
+
+- Descriptive names: the name says what the thing holds or does, without a comment.
+- Booleans read as a claim: prefix with `is`, `has`, `should` or `can`.
+- Where the language draws the distinction, constants and types are visually
+  distinct from ordinary values (`UPPER_SNAKE_CASE` and `PascalCase` in many
+  languages) — whether it draws it at all is for the language file to say.
 
 ## Code Smells to Avoid