Keep config-dependent reachability as needs_validation, not hardening

[jboiie]

Summary

Addresses gap 4 from #20: a real defect whose reachability depends on a deployment/configuration choice (e.g. a credentialed grant tied to an auth path that is not ambient in the checked-in config) gets downgraded to a hardening note. "Not reachable today" and "not a defect" are different claims, and a hardening note reads as the latter.

The existing rules already say a missing deployment fact should become needs_validation, but three places let it slip to hardening/rejected:

• HUNTING.md candidate gate rule 5 groups "missing best practice" with hardening, and "disproved by source" with rejection, with nothing in between for "inert in the checked-in config".
• SKILL.md anti-pattern 2 (defense-in-depth with no reachable violation) is easy to misapply to the same case.
• VALIDATION-AND-REPORTING.md lists "an impossible prerequisite" as grounds for rejected; a merely non-default prerequisite is not impossible.

Changes (docs only, +8/-1)

• HUNTING.md: rule 5 now says "not reachable in the checked-in configuration" is not "disproved by source". If a supported, documented, or shipped option would make the path reachable, use needs_validation naming that option. Hardening is reserved for paths no supported configuration reaches or that a visible control prevents.
• SKILL.md: "Respect source visibility" distinguishes a control that prevents the attack from a configuration that leaves the defect inert today.
• VALIDATION-AND-REPORTING.md: a non-default or absent-from-config prerequisite is not "impossible"; keep it needs_validation with that fact as the blocker.

No schema, validator, or ledger changes. This does not loosen the "only confirm established boundary failures" principle: these cases stay needs_validation with no severity.

Test plan

• Reviewed that existing needs_validation shape (blockers, validation_plan.deployment) already fits this case, so no schema change is needed.
• Ran node --test on both validator suites. Docs-only diff; the only failures are the pre-existing Windows O_NOFOLLOW/O_NONBLOCK CLI-test failures tracked in Fix CLI test suite hanging failures on platforms without O_NOFOLLOW/O_NONBLOCK #31 and its related PRs.
• Maintainers: a seeded-target re-run of the scenario in Six class-level gaps from a blind seeded-target comparison (n = 3 per arm) #20 gap 4 would be the real check.

Refs #20