fix(gh): move issues to In Progress when work starts #2616

Goal

Make the canonical issue-first workflow synchronize the Base Project Status when implementation work starts.

Background

basectl gh issue start currently validates the issue and prints the canonical branch/worktree command, but it does not move the linked Project item to In Progress. Work can therefore proceed while the board remains Backlog or Ready, as happened with #2612. The existing project issue set-fields --status repair path is manual and easy to miss.

Scope

• Update the canonical issue-start workflow to transition the linked Project item to In Progress.
• Use the existing REST-capable Project update path and verify the exact item after the write.
• Make the transition idempotent and explicit when Project access, item visibility, or readback fails.
• Preserve issue/category validation and canonical branch/worktree output.

Acceptance Criteria

• A successful basectl gh issue start <number> leaves the linked Base Project item at Status=In Progress.
• Repeating issue start is safe when the item is already In Progress.
• A failed or unverifiable Project transition returns a non-zero status and explains the repair command; it does not claim that work has started.
• The transition does not alter Priority, Area, Initiative, Size, labels, assignee, issue body, or branch naming.
• Tests cover successful, idempotent, delayed-visibility, and failed-readback paths.
• Documentation describes the status transition and the manual repair command.

Validation

• Focused Bash/Python Project workflow tests.
• Full local Base validation and stable compatibility checks.
• Hosted checks on the linked PR.

Non-Goals

• Automatically changing status on arbitrary git worktree or branch commands.
• Redesigning all PR/merge status transitions.
• Changing the Project schema or status vocabulary.

Project Fields

• Priority: P1
• Area: CLI
• Initiative: Contract Hardening
• Size: M