docs: clarify cross-section re-homes and resources scope in audit rules

Cross-section re-homes now ride the originating audit's commit instead
of needing a separate one, since both sides of the move land in one
diff. Also note that Resources sections are out of audit scope and
never parsed by the website, so they're not project entries subject
to the one-entry-per-commit rule.

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

CLAUDE.md

@@ -9,7 +9,8 @@ An opinionated guide to the best Python frameworks, libraries, tools, and resour
 [CONTRIBUTING.md](CONTRIBUTING.md) holds the admission rules, quality requirements, rejection rules, entry format, and ordering. Apply it whenever adding or removing an entry — direct commits included, not only PR reviews.
 
 - Every keep/drop reason must be verified against current online data at decision time — download counts, repo activity and archived status, PyPI metadata, project docs. Judging tiers — obvious choice vs challenger — also requires WebSearch evidence (adoption trajectory, community sentiment), not download counts alone. Training-data recollections are not evidence; label anything unverifiable as a judgment call.
-- One entry per commit when adding or deleting entries. Exceptions: a prune sweep is one commit per section, its body listing each removal with its reason; format, wording, or categorization changes may be bundled.
+- One entry per commit when adding or deleting entries. Exceptions: a prune sweep is one commit per section, its body listing each removal with its reason; format, wording, or categorization changes may be bundled. Cross-section re-homes ride the originating audit's commit (both sides of the move in one diff).
+- Resources sections are not project entries: out of audit scope, and the website never parses them.
 - Sponsor placement never influences which projects get listed — see [SPONSORSHIP.md](SPONSORSHIP.md).
 
 ## Gotchas