Fix forward #286: derive Grok live-gate reach from runtime ownership #287

Introduced by: #286

The merged head of #286 (e4537f0) has Unfret finding v1:427364ab, "New Grok home resolver is omitted from feature selection". .claude/skills/verify-open-pstack/scripts/io.ts, where #286 put grokHome(), is not in GROK_REACH, so a change to it cannot name grok:setup. This is the second consecutive verdict on the same exact-path list. The step-back exchange chose to replace the list.

Acceptance criteria

1. The exact-path list is gone. GROK_REACH, its loop and GROK_TRANSPORT are deleted from .claude/skills/verify-open-pstack/scripts/core.ts.
2. Every runtime ownership branch permits the Grok features. Each branch of classify() grants both grok:dispatch and grok:setup. The branches are:
   • catalog;
   • shared and the shared recipe;
   • project;
   • recognized skill content;
   • the transcript resolver.
3. The narrow cases stay narrow. Asset-only, version-only manifest and non-runtime changes gain no Grok feature, and unmapped paths still fail.
4. Tests cover the new rule. Every previously omitted path and scripts/io.ts can select both Grok features, and so can a new file under an existing runtime prefix. Self-test adds no Grok session.
5. The docs match. features/grok.md says that recognized runtime code and instructions permit naming the Grok features, and it names the asset and version-only exceptions instead of listing files.

Out of scope: T3_DISPATCH_PATHS has the same mechanism, as an advisory with no observed failure.