STALE_FILE commit-count warnings drown out real drift findings

[theyashasvipandey]

STALE_FILE warnings are driven only by commit counts. On an active repository they outnumber
every other finding, and they don't say whether anything the file describes actually changed.

Measured on mex's own scaffold (clean checkout, fresh graph, main @ 2f074dc):

• 17 STALE_FILE warnings out of 37 issues in total, e.g.
  170 commits since file was last updated (threshold: 50). A clean clone of today's main
  reports 20.
• They include patterns/README.md, which is generated prose.
• The real findings in the same report (6 drifted groundings, a grounding pointing at a removed
  node) sit among them.

The score drops to 0/100, so it no longer distinguishes a neglected scaffold from a healthy one
on a busy repository.

Why it's noise: commits to the repository aren't changes to what a file describes. A
context/stack.md can be correct across 500 commits; a pattern can be wrong after one.

Possible directions

• Count only commits that touched paths the file references or grounds (paths from its claims,
  files of its grounded nodes). A file with no references falls back to time, not commits.
• Or make STALE_FILE informational and exclude it from the score, since grounding and path
  checks already measure actual drift.
• Skip generated files (patterns/README.md, patterns/INDEX.md).