[v2] Bifrost work item source adapter

[devzeebo]

Part of the Orchestrator v2 rebuild — a tear-down/rebuild in a new self-contained orchestrator-v2/ folder (Vite+ / vp, vp test + vitest-gwt, no hooks, single RPC/WebSocket runner interface, engine adapters copied wholesale). See #29 (runner split), #30 (Task Agent), #31 (Workflow Agent).

Problem

v2 needs to reconnect to the real Bifrost backend so work items flow end-to-end through the new architecture. The v2 work item source must expose first-class dependencies and draft/live states mapped onto Bifrost runes — keeping dependency resolution inside the source (not the orchestrator), and keeping Bifrost as just one of many work item sources.

Proposed solution

New work-item-source-bifrost package (ports v1 task-source-bifrost):

• Promote RuneDetail.dependencies (already encoded at orchestrator/packages/task-source-bifrost/src/bifrost-task-source.ts:157) to first-class dependency edges.
• Map createDraftWorkItem / promoteDraftToLive / setDependency / transitionStatus to the appropriate Bifrost API calls (draft → pending/open rune; live → ready rune; setDependency → rune relationship).
• watchWorkItems yields only live + dependency-satisfied runes (resolution stays in the source).
• Adaptive polling ported from v1 (ADR-002).

Alternatives considered

• Reference the v1 package across the folder boundary — rejected; v2 is self-contained (this is a port that talks to the Bifrost HTTP API, not a cross-folder import).

Area

Orchestrator v2 / work-item-source-bifrost

Acceptance criteria

• With a mocked HTTP client (reuse v1 test patterns): dependency mapping, draft/live gating, and polling behave correctly.
• watchWorkItems withholds non-live / dependency-blocked runes.
• Optional: integration against a staged Bifrost instance.

Dependencies

• [v2] Work item source with dependencies + draft/live

Verification

vp test + vitest-gwt with a mocked HTTP client: draft/live + dependency mapping/gating/polling.