wayfinder: prefer native blocking, and say why

The blocking rule now leads with the tracker's native dependency
relationship and encodes the rationale: native rendering makes the
frontier visible in the tracker's own UI, so the human sees what's
takeable without opening the map. Notes the body-convention fallback
for trackers that lack native blocking (GitHub has it; GitLab only on
paid tiers).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

skills/in-progress/wayfinder/SKILL.md

@@ -52,7 +52,7 @@ Two label families:
 - `wayfinder:<type>` — one of `research`, `prototype`, `grilling`, `task` (see [Ticket Types](#ticket-types)).
 - `wayfinder:claimed` — a session sets this **first**, before any work, so concurrent sessions skip it.
 
-Blocking uses the tracker's native semantics. A ticket is **unblocked** when every ticket blocking it is closed. The **frontier** is the open, unblocked, unclaimed children — the edge of the known.
+Blocking uses the tracker's **native** dependency relationship wherever the tracker has one. Native is essential, not cosmetic: it renders the frontier _visually_ in the tracker's own UI, so the human sees what's takeable at a glance without opening the map. Only where a tracker has no native blocking does the mechanics fall back to a body convention. A ticket is **unblocked** when every ticket blocking it is closed; the **frontier** is the open, unblocked, unclaimed children — the edge of the known, and what the human picks from.
 
 The answer isn't part of the body — it's recorded on resolution (see [Work through the map](#work-through-the-map)). Assets created while resolving a ticket are linked from the issue, not pasted in.