Feat #16: Use git worktree instead of git checkout in work-issue workflow

[ydesgagn]

Summary

Closes #16. Replaces the git checkout -b branching strategy in commands/work-issue.md Step 3 with git worktree add, so each issue gets its own isolated working directory. The user's main checkout is no longer disrupted by git fetch + git checkout and multiple issues can be worked on in parallel without stashing.

Key changes:

• commands/work-issue.md Step 3 ("Prepare repository" → "Prepare an isolated worktree"): the new flow runs git worktree add ".worktrees/$BRANCH" -b "$BRANCH" "origin/$DEFAULT_BRANCH" instead of git checkout -b, then cds into the worktree for the rest of the workflow.
• Added a pre-flight that ensures .worktrees/ is gitignored in the target repo before creating the worktree (auto-adds + commits if missing) so worktree contents never pollute git status.
• Worktree is always based on the freshly fetched origin/$DEFAULT_BRANCH, never the user's current HEAD — this preserves the "always start from latest default" guarantee without needing to checkout the default branch in the user's main worktree.
• submodule update --init --recursive runs inside the new worktree (each worktree has its own submodule state).
• Step 11 (Cleanup) now offers two paths: keep the worktree (default — useful for follow-up review/iteration) or git worktree remove ".worktrees/$BRANCH" once the PR has merged. Force-remove only with explicit user confirmation.
• Added a note pointing users at the harness-level claude --worktree <name> flag as an alternative for whole-session isolation.

Types of changes

• Bugfix (fixes an issue)
• New feature (adds functionality)
• Refactoring (improves code without changing functionality)
• Breaking change (incompatible changes)
• Build or security update (updates dependencies, libraries, or security patches)
• Code style or documentation update (formatting, renaming, or documentation changes)
• Other (please describe):

Checklist

• Unit tests added to validate my fix/feature
• I have manually tested my change
• I did not add automation test. Why ?: command files are markdown specs; this repo has no automated test framework. Verified with linters (0 errors) and a manual read of the new Step 3 / Step 11 against the rest of the workflow.
• Database changes requiring migration with downtime or reprocessing of existing data
• The SOUP file lists the risk Level, requirements and verification reasoning associated with each library
• readme.md includes sections on introduction, installation, usage, and contributing
• docs/architecture.md includes sections on the architecture diagram, software units, software of unknown provenance, critical algorithms and risk controls related to PII and security
• Impact on PII, privacy regulations (CCPA/GDPR/PIPEDA), CIS benchmarks or security (availability/confidentiality/integrity); management must be notified