Implement

Implement a GitHub issue end-to-end: fetch the issue, plan, code with approval, commit incrementally, and generate a PR summary.

The argument is an issue number (e.g. `/implement 42`) or a full GitHub URL (e.g. `/implement https://github.com/armadaproject/armada-spark/issues/42`). If no argument is given, ask the user.

## Phase 1: Fetch issue

1. Parse the argument:
   - If it is a full URL like `https://github.com/{owner}/{repo}/issues/{number}`, extract `{owner}/{repo}` and `{number}`.
   - If it is just a number, use the current repo (run `gh repo view --json nameWithOwner -q .nameWithOwner` to get it).
2. Fetch issue details:

gh issue view --repo <owner/repo> --json title,body,labels,assignees,comments

3. Display a summary to the programmer:
- Issue number and title
- Labels (if any)
- Body (truncated to ~40 lines if longer)
- Number of comments and any noteworthy discussion points
4. Ask the programmer to confirm this is the right issue before proceeding. Use AskUserQuestion with options: "Proceed", "Show full issue body", "Cancel".

## Phase 2: Branch setup

1. List all configured remotes: `git remote -v`
2. If there is more than one remote, ask the programmer which remote to use as upstream using AskUserQuestion (list the remote names as options).
If there is only one remote, use it automatically.
3. Fetch and update master from the chosen remote:

git fetch git checkout master git pull master

4. Create a new branch from master. The branch name must follow this convention:
- Format: `<type>/<short-slug>` where `<type>` is a Conventional Commits type (`feat`, `fix`, `refactor`, `docs`, `chore`, etc.) and `<short-slug>` is a kebab-case summary derived from the issue title (3-5 words max).
- Examples: `feat/dynamic-allocation-support`, `fix/event-watcher-reconnect`, `refactor/pod-spec-converter`
- Pick the type based on the issue labels and description (e.g. a bug report maps to `fix/`, a feature request to `feat/`).

git checkout -b /

5. Confirm to the programmer: "Created branch `<branch-name>` from `<remote>/master`."

## Phase 3: Plan

1. Based on the issue description, explore the codebase to understand the relevant code paths. Use subagents to search for files, classes, and patterns referenced in or implied by the issue.
2. Create an implementation plan with numbered steps. Each step should be a logical, committable unit of work. The plan must include:
- A 1-2 sentence summary of the issue
- Numbered steps, where each step has a title, a description of what to change, and the affected file paths
3. Save the plan to `plans/implement-<issue-number>.md` using this format:

Issue #: