Maintainer-side hardening: expand CODEOWNERS coverage and evaluate an LLM-slop pattern linter

Follow-up to #2172 and #2174. Two maintainer-side hardening items that benefit from community input before implementation.

1. Expand CODEOWNERS coverage to every cheat sheet

.github/CODEOWNERS currently names subject-matter owners for ~20 cheat sheets (mostly @kwwall's areas). Every other cheat sheet falls to the two global defaults (@mackowski, @jmanico).

Branch protection already requires CODEOWNERS approval, but the bottleneck is that two people end up named on the vast majority of PRs. Expanding ownership to a named SME per cheat sheet would:

• Surface the most-qualified reviewer automatically on every PR.
• Distribute review load away from the two global owners.
• Make "no qualified reviewer is paying attention" PRs visible — a CODEOWNERS gap becomes a visible signal.

Asks:

• Volunteers willing to be named owners for specific cheat sheets (one or two cheat sheets per person is fine — we are not asking for unbounded triage duty).
• Comment on this issue with the cheat sheet(s) you would own.
• Owners commit to either reviewing within ~14 days or explicitly hand off; no review SLA beyond that.

A draft expanded CODEOWNERS will follow once we have enough volunteers to cover the bulk of the catalog.

2. Evaluate an LLM-slop pattern linter

Proposal: a CI check that scans the diff for high-signal LLM stylistic tells and fails the build (or just comments) when density exceeds a threshold. Candidate patterns:

• Boilerplate openers/closers: "in today's rapidly evolving threat landscape", "in conclusion", "it is important to note that", "navigating the complexities of".
• Marketing-style adjectives applied to mechanisms: "robust and scalable", "cutting-edge", "comprehensive", "seamless".
• Filler verbs: "delve into", "leverage", "harness the power of".
• Suspicious em-dash density (LLMs over-produce em-dashes vs. typical human writers).
• Numbered-list-of-three pattern with no citations.

Open questions for the community:

• Hard fail or advisory comment? Advisory avoids false-positive damage; hard fail has more teeth.
• Pattern list governance — who maintains it, how often is it reviewed?
• False-positive tolerance: ESL contributors and long-time technical writers will occasionally trip these patterns. Acceptable?
• Does this duplicate work better done by human reviewers, given the citation-check and scope-check in #2174 are already catching the worst cases?

Discussion welcome before any implementation PR. If consensus is "advisory comment only," the implementation is trivial.

Refs #2172, #2174