Add interactive GitHub issue linking and common PR operations

[SnowCheetos]

Summary

Extend the existing autocommit pr implementation so generated or updated pull requests can link against existing GitHub issues, with interactive CLI support as the primary user experience and command flags as the scripted/non-interactive path. The same pass should expose common GitHub PR/issue metadata operations that map cleanly to the already-used gh backend.

Current tree state on main:

• crates/cli/src/main.rs already dispatches autocommit pr.
• crates/cli/src/cmd/pr.rs already generates PR titles/bodies, supports interactive editing, --push, --dry-run, --draft, --base, --head, --title, and --body.
• crates/cli/src/cmd/pr.rs already shells out to gh pr create, detects existing open PRs with gh pr list --json number,title, updates existing PRs with gh pr edit, and falls back to gh api PATCH repos/:owner/:repo/pulls/{number} when needed.
• crates/cli/Cargo.toml uses clap, dialoguer, gix, indicatif, serde, and serde_json; there is no GitHub SDK dependency in tree today. The current architectural fit is therefore to keep building on the existing gh command adapter boundary.

Primary interactive behavior

When autocommit pr runs interactively, the PR flow should guide the user through GitHub linkage and metadata before creation/update:

1. Generate the PR title/body as it does today.
2. Ask whether to link existing GitHub issues.
3. Let the user search/list open issues, select one or more, or enter an issue number/URL manually.
4. Ask how selected issues should be referenced:
   • Refs by default, leaving issues open after merge.
   • Closes, Fixes, or Resolves when the user wants merge-time closure.
5. Offer common metadata prompts when supported by gh:
   • reviewers
   • assignees
   • labels
   • milestone
   • draft vs ready
   • web mode when the user wants to finish in GitHub UI
6. Show the final PR preview, including linked issues and metadata, before mutation.

The interactive path should remain useful even when the user does not remember issue numbers. Issue discovery can start with gh issue list --json number,title,state,labels,url and optionally accept a search string that maps to gh issue list --search.

Flag/scripted behavior

Flags should mirror the interactive choices for automation and non-interactive use:

autocommit pr --issue 123
autocommit pr --issue 123 --closes
autocommit pr --issue https://github.com/MicroPerceptron/autocommit/issues/123
autocommit pr --issue 123 --issue 456 --fixes
autocommit pr --issue 123 --reviewer monalisa --label enhancement
autocommit pr --issue 123 --dry-run --no-interactive

Metadata flags that are supported by the installed gh CLI and should be considered for the same pass or follow-up subcommands:

autocommit pr --reviewer monalisa
autocommit pr --assignee @me
autocommit pr --label enhancement
autocommit pr --milestone "Version 1"
autocommit pr --web
autocommit issue list --label enhancement --json
autocommit issue view 123 --json

Issue-linking semantics

• --issue <number-or-url> and the interactive issue picker both append a stable issue reference block to the generated PR body.
• Default references should be non-closing, for example Refs #123.
• --closes, --fixes, or --resolves should switch the body reference to GitHub closing keywords, for example Closes #123, so the issue closes when the PR merges.
• Multiple issues should be accepted and de-duplicated.
• Existing body text from --body or interactive editing must be preserved; issue references should be appended or updated without duplicating prior references.
• --dry-run must show the final title/body/metadata, including issue references, without creating or updating a PR.
• Issue verification should happen before mutation using gh issue view <id-or-url> --json number,state,title,url unless a deliberate escape hatch such as --no-verify-issue is added.

Implementation shape

• Extend PrArgs in crates/cli/src/cmd/pr.rs with issue-linking and metadata fields rather than adding a parallel PR path.
• Extend the existing interactive PR flow in pr.rs instead of creating a separate issue-linking mode.
• Extract repeated gh invocations behind a small internal helper so issue verification, issue search/list, PR create, PR update, and future issue view/list operations share error handling and command construction.
• Reuse existing PR body generation by adding a focused function that appends or replaces an ### Linked issues block.
• Treat command flags as preselected answers in interactive mode. For example, --issue 123 should pre-populate linked issues but still allow preview/edit unless --no-interactive or --yes skips prompts.
• Pass PR metadata to gh pr create when creating new PRs:
  • --reviewer
  • --assignee
  • --label
  • --milestone
  • --web
• When updating an existing PR, use gh pr edit equivalents where supported:
  • --add-reviewer
  • --add-assignee
  • --add-label
  • --milestone
  • --body
  • --title
• Add issue list / issue view only if the command surface stays small and maps directly to gh issue list / gh issue view; otherwise keep this issue focused on PR creation/update linkage.

Acceptance criteria

• In interactive mode, autocommit pr can list/search issues, select one or more issues, choose Refs vs a closing keyword, preview the final PR, and create/update it.
• In interactive mode, explicit flags such as --issue, --closes, --reviewer, and --label prefill the flow rather than bypassing it unless --no-interactive or --yes is used.
• autocommit pr --issue <n> --dry-run renders a PR body with Refs #<n> and performs no GitHub mutation.
• autocommit pr --issue <n> --closes creates or updates a PR body with a GitHub closing reference such as Closes #<n>.
• URL-form issue references normalize to the same body format as numeric references.
• Re-running with the same issue does not duplicate issue references.
• Missing issues, missing gh, unauthenticated gh, and malformed issue references fail before PR mutation with clear errors.
• Tests cover issue reference parsing, closing-keyword selection, duplicate suppression, linked-issues body rendering, dry-run output, interactive prefill behavior, and command construction without requiring live GitHub auth.

Design notes

This should remain CLI orchestration. autocommit-core should stay focused on diff analysis and report generation, while GitHub auth/network behavior stays isolated in the CLI command layer that already owns git and gh subprocess use. The feature should match the rest of the CLI: interactive first for humans, flags for repeatable automation.