Orchestrator must claim all issues upfront in multi-issue runs

[Trecek]

Problem

When the orchestrator processes multiple issues (e.g., "work on issue #401 and #444 for implementation recipe"), claim_issue is only called inside each recipe execution as it begins work on that specific issue. This means:

• Issue Orchestrator must detect merge queue and sequence merges for non-queue repos #444 remains unclaimed while Auto-merge should work without merge queue — direct merge fallback #401 is being processed
• Another pipeline session can pick up Orchestrator must detect merge queue and sequence merges for non-queue repos #444 and start duplicate work
• The race window grows linearly with the number of issues being processed
• This defeats the purpose of the claim/release protocol for multi-issue workloads

The root cause is in the process-issues skill, which explicitly defers claiming to each recipe's internal claim_issue step rather than claiming all issues upfront. The claim_issue MCP tool itself also only accepts a single issue_url — there is no batch claim capability.

Proposed Solution

1. Add batch upfront claiming at the orchestration layer: Before process-issues begins dispatching recipes, it should call claim_issue for every issue in the manifest. Issues that fail to claim (already claimed by another session) should be skipped from the batch.

2. Add a claim_issues (plural) convenience tool or loop: Either add a batch-capable MCP tool, or have the orchestrator loop through all issues calling claim_issue before starting any recipe dispatches.

3. Retain per-recipe claim_issue as a safety net: The existing claim_issue steps inside recipes should remain as defense-in-depth (they'll see the label already applied and return claimed: false with a note that the current session owns it — this may need a small adjustment so the recipe doesn't abort when the label was already applied by the same orchestration session).

4. Ensure release_issue cleanup covers all claimed issues on failure: If the orchestrator claims 5 issues upfront but fails on issue Feature: read_db MCP tool for read-only SQLite queries #2, issues Feature: pipeline context for inter-step data passing #3-Add orchestrate CLI command with hard tool restrictions #5 must be released.

Acceptance Criteria

1. All issues in a multi-issue run are claimed before any recipe execution begins
2. Issues already claimed by another session are identified and skipped upfront
3. On orchestrator failure, all upfront-claimed but unprocessed issues are released
4. Per-recipe claim_issue steps continue to work as defense-in-depth without aborting when the label was already applied by the same session
5. Existing single-issue recipe flows are unaffected

Requirements

BATCH

• REQ-BATCH-001: The process-issues skill must call claim_issue for every issue in the triage manifest before dispatching any recipe execution.
• REQ-BATCH-002: The system must iterate through all issues in the manifest and call claim_issue individually for each, collecting results before proceeding.
• REQ-BATCH-003: Issues where claim_issue returns claimed: false (already claimed by another session) must be excluded from the dispatch list and logged as skipped.

COMPAT

• REQ-COMPAT-001: Per-recipe claim_issue steps must not abort when the in-progress label was already applied by the same orchestration session's upfront claim.
• REQ-COMPAT-002: The claim_issue tool's on_result routing in recipes must treat a pre-existing label applied by the current session as a proceed condition, not an escalate-stop condition.
• REQ-COMPAT-003: Single-issue recipe flows (no orchestrator) must continue to function identically to current behavior.

RELEASE

• REQ-RELEASE-001: The process-issues skill must release all upfront-claimed but unprocessed issues when the orchestrator encounters a fatal failure.
• REQ-RELEASE-002: The system must track which issues were claimed upfront and which have been handed off to recipe execution, so that only uncompleted issues are released on failure.
• REQ-RELEASE-003: Issues that completed recipe execution (success or recipe-level failure with its own release) must not be double-released by the orchestrator cleanup.