MISSING_PATH false positives: negation only heading-scoped, non-path tokens treated as paths, dot-dir glob blind spot

[m3]

Summary

mex check (0.7.0-0.7.2) emits MISSING_PATH errors for files that are intentionally absent or were never paths at all, which zeroes drift scores on healthy repos.

Three defects

1. Negation is heading-scoped only (isNegatedSection). Bullets describing deletions inside normal sections — e.g. "Deleted orphaned files: check_commands.js, ..." — still produce path claims for intentionally-absent files.
2. Non-path tokens extracted as paths: ELO-style deltas (+/-N), overall/overall, middot lists (8ball/pro · 9ball/pro), globs (web/routes/admin/*.js), trailing dirs (screenshots/).
3. Dot-directory blind spot: the fallback filename glob lacks dot: true, so a backticked deploy.yml living in .github/workflows/ never matches, producing a false error.

Repro and evidence

Full root-cause plus a verified fix against our installed 0.7.0:

• added inline line-level negation context (deleted / removed / dropped / retired / orphaned / unreferenced / no longer)
• NON_PATH_TOKEN filter for deltas, middot lists, globs and trailing dirs before claim extraction
• negated/implausible claims demote MISSING_PATH from error to warning (visible as noise, not score killers)
• dot: true on the fallback filename glob

Verified across a 10-project estate: one project went from 23 MISSING_PATH errors (score 0) to 0 errors; 7 known-good projects stayed 100/100.

Happy to send the patch diff or open a PR if useful.

[Yashasvi2229]

Thanks — good report, all three confirmed against main (0.7.3).
PR very welcome.

One thing to settle first: the error→warning demotion. The other three changes fix
detection and I'd take them as-is, but demotion doesn't remove a false positive, it
just makes it cheaper — costs are flat per issue with no cap, so it takes ~34 to floor
the score instead of ~10. Bigger bucket, same leak.

My instinct: if NON_PATH_TOKEN is confident a token isn't a path, drop it before it
becomes a claim — no issue, no points. Anything that survives into a claim deserves
error. Is there a case where the filter is confident enough to demote but not
confident enough to drop?