feat(workstation): require targets cardinality on workflow registry

[gfargo-horizon-agent]

What

Makes workflow cardinality (targets: 'single' | 'multi') a required, complete, load-bearing contract on LogInkWorkflowAction, and makes the confirm overlay branch on that declared contract instead of inferring cardinality from resolver output length.

Why

Plane: OSS-674

Note: #1361's multi-select UX already shipped and introduced targets ad-hoc as an optional field, a plural-shaped resolver (ids: string[]), and a pluralizing confirm overlay. What was still missing — and what this PR closes — is the completeness and enforcement half: every registry entry explicitly declaring its cardinality, the type system rejecting entries that don't, and the overlay reading the declared contract rather than guessing from output shape.

How

• inkWorkflows.ts: targets?: → targets: (required), forcing tsc to flag every entry missing it; tagged all 118 previously-untagged entries as targets: 'single' (the existing 4 batch-capable workflows — cherry-pick-commit, delete-branch, force-delete-branch, drop-stash — were already 'multi').
• overlays.ts: describeConfirmationTarget now resolves the action via getLogInkWorkflowActionById and only takes the plural branch when action.targets === 'multi', so a 'single' workflow can never render a plural summary even if marks are active.
• Added a completeness test (no entry omits targets), a closed-set test pinning the exact four 'multi' ids, and a resolver-alignment test tying the contract to the batch-selector implementation.
• Added an overlay regression test proving a 'single' workflow (checkout-branch) keeps its singular confirm line even with marks active on other branches.

Deliberate deviation from the ticket text: resolvePendingItemAction is not rewritten to return LogInkPendingItemAction[]. It already satisfies the underlying need — it returns ids: string[], and the three batch-capable workflows already populate it with N ids via the existing batch selectors. Wrapping that in an outer array would be a no-op refactor touching overlays.ts, useWorkflowAction.ts, sidebar.ts, four surface files, and pendingItemAction.test.ts for no new capability.

Testing

• build passes (npm run build)
• tests pass — inkWorkflows.test.ts + overlays.test.ts (55/55), full suite run locally
• lint clean (npm run lint, 0 errors)
• CI: pending

🤖 Generated by the harbor agent loop. Reviewed by a human before merge.

[gfargo-horizon-agent]

🔎 Agent review (sonnet) — LGTM

REVIEW: LGTM
RESOLVES: full

The PR correctly implements the completeness/enforcement contract: all 122 registry entries now carry an explicit targets field (verified mechanically), exactly the four batch-capable workflows are 'multi', and describeConfirmationTarget now gates the plural branch on the declared contract rather than resolver output length. Tests (55/55), lint (0 errors), and tsc --noEmit all pass, and the deliberate deviation from rewriting resolvePendingItemAction to return an array is well-justified and clearly documented in the PR body.