Add Wayfinder orchestration for persistent decision maps

[BjRo]

Motivation

Large, uncertain efforts can span multiple agent sessions and repositories. Darrow Discovery works through questions in one read-only conversation, Darrow Tickets handles tracker operations, and Darrow Decisions keeps settled choices with their authoritative owners. Add a persistent planning map that coordinates these responsibilities until the route to a bounded destination is clear.

Reference: https://github.com/mattpocock/skills/tree/main/skills/engineering/wayfinder

Acceptance criteria

• Add an independently installable, explicitly invoked Wayfinder orchestration plugin under plugins/orchestration/. It owns planning continuity and completion, not production implementation.
• A map has one nominated home repository and may cover an explicit list of participating repositories. Adding a repository later requires a scope change.
• Charting establishes the destination, first precisely stated question tickets, not-yet-specified areas, and out-of-scope work. Show the proposed map for approval; create no tracker objects before approval. After approval, persist one map and its initial child tickets.
• A read-only map view shows the destination, linked decisions so far, not-yet-specified areas, out-of-scope work, and the open, unblocked, unclaimed frontier without claiming or mutating anything.
• A work invocation resolves at most one question. It can take a named eligible question or select the next frontier question when none is named. The method follows the question rather than a mandatory set of ticket types. A prototype, if needed to answer a question, is its own child ticket; its artifact and finding stay linked there.
• Independent questions may be worked concurrently, including by sessions using the same tracker account. A claim distinguishes sessions and prevents duplicate ownership. An abandoned claim is released or reassigned explicitly, never on a timeout alone. Concurrent map updates must not lose another session's work.
• Record a question's full answer and supporting assets on its ticket. Before closing a question whose answer establishes a lasting rule, record that rule at its authoritative owner and link it; ticket-local choices may remain in the ticket. Append only a short linked gist to the map.
• After a resolution, update the map and turn newly precise in-scope questions into child tickets. Remove corresponding not-yet-specified entries. Report partial tracker effects and make retry safe from duplicate maps, tickets, answers, or map entries.
• Complete the map only when no in-scope questions or not-yet-specified areas remain. Return a short handoff summary with links. Do not automatically write a specification or implement the destination.
• Special Wayfinder labels are optional. Apply existing labels when useful; do not require pre-created labels or treat labels as claims, parent links, or blockers.
• Use a compatible ticket capability through its public operations, without embedding a tracker adapter in Wayfinder. Missing required operations or unavailable authoritative decision owners must stop with a clear, accurate account of what was and was not persisted.

Existing capability gaps

Darrow Tickets already supports existing labels, parent and dependency relations, comments, closure, and description edits. Its current public operations need a compatible way to create map and question-shaped tickets, query a map's children with blocker and claim state, claim an existing ticket distinctly per session, read resolution history as needed, and update the shared map safely. Keep provider mechanics inside the ticket capability.

Verification

• An unapproved chart leaves the tracker unchanged; an approved chart produces the agreed map and children once.
• A map with blocked, claimed, and available children reports the correct read-only frontier.
• Two overlapping sessions sharing an account cannot claim the same question; independent questions can proceed without lost map updates.
• A broader decision remains open until its canonical record is linked. A completed map has no unresolved in-scope question or fog and produces a handoff without a spec or implementation.