[Unit PRs] Show unit delivery status and dependency blockers in the intent UI #565

Part of #553. Suggested step 11 of 13; one focused PR into main.

Outcome: Users can see each unit's actual delivery destination, PR and reason for waiting, including partial delivery and already delivered work after recovery.

Depends on: #561, #562, #563

Scope

• Extend existing intent/unit API projections and frontend types with the agreed delivery fields rather than adding a second status source.
• Display building, awaiting required gate/review, awaiting merge, delivered, blocked and partial outcomes in the existing lane/review components.
• Link the exact unit PR/repository and explain unsatisfied dependencies. Preserve delivered results across refresh, reconnect and recovery.
• Keep legacy intent-branch integration labels distinct from delivery to the configured base; respect existing project access and capability checks.

Acceptance criteria

• A dependent shows its unresolved predecessor(s), and transitions only when backend delivery truth changes.
• Partial multi-repository outcomes and corrected/published attempts remain understandable without losing PR links.
• Refresh/reconnect yields the same status as initial load; stale data from another intent/project cannot overwrite it.
• Users without access cannot obtain delivery data through new fields or links.
• Focused API/component tests and frontend build pass for new and existing strategies, including no-change and unavailable-status cases.

PR boundary and rollout

Existing intent delivery presentation and its required API/type changes only. No new dashboard, notification system, redesign of all execution states or strategy selector.

Starting points

frontend/src/components/intent/UnitLaneBoard.tsx, frontend/src/components/intent/UnitBranchEntry.tsx, frontend/src/components/v2/UnitLaneGraph.tsx, frontend/src/services/intents.ts, lambda/intents/index.js.

Planning baseline: main at b5d68d5d2f12292d56a21aab917e4d8f9538aa0b (2026-10-15). Recheck current main and applicable guidance before implementation. Existing strategies remain supported; the new capability stays disabled until qualification.