Add diff-scoped extended-lint script for comment-content and repetition smells clippy can't catch

[jordigilh]

Summary

Clippy already denies the machine-checkable half of "low-effort code"
smells (unwrap/expect, panic!, todo!()/unimplemented!(),
dead_code, missing_docs, print/dbg! macros, etc., per this crate's
[lints] table and clippy.toml). What lint tooling structurally cannot
check is comment content and diff-local repetition -- two common
low-effort-code tells that show up regardless of whether the code was
written by hand or with AI assistance (this project's own
CONTRIBUTING.md/docs/conventions.md already hold both to the same bar:
"every contributor is responsible for the code they submit").

Concretely, today nothing in CI catches:

• Leftover TODO/FIXME/XXX/HACK markers left in from a work-in-progress
  commit.
• Commented-out code left behind after a refactor.
• Comments that just narrate what the next line does (docs/conventions.md
  already states "Comments answer 'why?', never 'what?'" as a convention,
  but nothing enforces it).
• The same numeric/string literal repeated 3+ times in a diff instead of
  being hoisted into a named constant (docs/conventions.md calls out magic
  constants as something to avoid).
• New #[allow(clippy::...)]/#[expect(clippy::...)] suppressions added
  without an accompanying justification.

Proposing a small, diff-scoped Python script (scripts/extended-lint.py)
that scans only lines added/changed versus the diff base, so pre-existing
code is never relitigated, and wires into the existing lint CI job
alongside make lint/make doc.

Evidence

• Cargo.toml [lints] / clippy.toml: covers the structural half already.
• docs/conventions.md "Comments vs Tracing" and "Additional Coding
  Conventions" sections: state the conventions this script would help
  enforce, but nothing currently checks them mechanically.
• .github/workflows/tests.yaml lint job: currently runs make lint
  (clippy + fmt) and make doc; no diff-content check exists.

Risk

None from not doing this beyond the status quo: these are style/hygiene
gaps, not correctness bugs, and this is a pre-GA alpha project. This is a
quality-of-life proposal, not an urgent finding.

Suggested fix

Add scripts/extended-lint.py (BLOCK on TODO markers and commented-out
code; WARN on narrating comments, repeated literals, weak identifier names,
and new clippy suppressions), a make extended-lint target, and a step in
the CI lint job that fetches the PR's base branch and runs it. See the
implementation in the linked pull request.

Severity: Low (developer-experience / code-hygiene enhancement)

[jordigilh]

Closing this out without merging.

After digging into what actually exists in the Rust ecosystem for this class of check, most of the "extended lint" heuristics either have no reliable off-the-shelf equivalent in any language's tooling (commented-out-code detection, "narrating" comment detection), or only partial overlap that does not justify maintaining bespoke regex/diff-scoped Rust across six repos (e.g. TODO markers are trivially a one-line git diff | rg in CI rather than a dedicated tool; new-clippy-suppression tracking is already better covered by denying clippy::allow_attributes outright rather than diff-scoping it).

Decision: we do not want to own and maintain custom heuristic lint logic per-repo. If this capability is worth having, the better path is contributing it upstream to a maintained linter (clippy itself, or a dylint/ast-grep rule set) rather than a bespoke xtask subcommand we would need to keep in sync across the org. Not pursuing this further for now.

[jordigilh]

Follow-up on the reasoning above, now that all six ports are done: implementing this surfaced a concrete illustration of exactly the maintenance burden we did not want to sign up for. Every one of the six independent Rust ports had to hand-write a workaround for the same problem -- the linter's own source (its regex definitions, doc comments, and test fixtures) legitimately contains the words TODO/FIXME/etc. as text, so without a manual self-exclusion pathspec the tool blocks on itself. That is not a one-time fix; any future contributor touching this logic (or writing a similar comment-content check) will hit the same trap and need to know to work around it by hand -- exactly the kind of "requires follow-up before it can be safely enabled" friction that is not simple to apply, and part of why we are not carrying this ourselves.