fix(quick-dev): use absolute paths in code -r invocations (#2087)

* fix(quick-dev): use absolute paths in code -r invocations

Agent CWD may differ from the project root in worktree setups,
causing relative paths to silently fail. Resolve paths via
git rev-parse --show-toplevel before invoking code -r.

* fix(quick-dev): add CWD fallback when git rev-parse fails

Adds graceful fallback to current working directory when
git rev-parse --show-toplevel fails (VCS unavailable).

src/bmm-skills/4-implementation/bmad-quick-dev/step-05-present.md

@@ -53,7 +53,7 @@ When there is only one concern, omit the bold label — just list the stops dire
 1. Change `{spec_file}` status to `done` in the frontmatter.
 2. If version control is available and the tree is dirty, create a local commit with a conventional message derived from the spec title.
 3. Open the spec in the user's editor so they can click through the Suggested Review Order:
-   - Run `code -r "{spec_file}"` to open the spec in the current VS Code window (reuses the window where the project or worktree is open). Always double-quote the path to handle spaces and special characters.
+   - Resolve two absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) `{spec_file}`. Run `code -r "{absolute-root}" "{absolute-spec-file}"` — the root first so VS Code opens in the right context, then the spec file. Always double-quote paths to handle spaces and special characters.
    - If `code` is not available (command fails), skip gracefully and tell the user the spec file path instead.
 4. Display summary of your work to the user, including the commit hash if one was created. Any file paths shown in conversation/terminal output must use CWD-relative format (no leading `/`) with `:line` notation (e.g., `src/path/file.ts:42`) for terminal clickability — the goal is to make paths clickable in terminal emulators. Include:
    - A note that the spec is open in their editor (or the file path if it couldn't be opened). Mention that `{spec_file}` now contains a Suggested Review Order.

src/bmm-skills/4-implementation/bmad-quick-dev/step-oneshot.md

@@ -36,7 +36,7 @@ If version control is available and the tree is dirty, create a local commit wit
 ### Present
 
 1. Open all changed files in the user's editor so they can review the code directly:
-   - Run `code -r "{project-root}" <changed-file-paths>` — the project root as the first argument, then each changed file path. Always double-quote paths with spaces.
+   - Resolve two sets of absolute paths: (1) the repository root (`git rev-parse --show-toplevel` — returns the worktree root when in a worktree, project root otherwise; if this fails, fall back to the current working directory), (2) each changed file. Run `code -r "{absolute-root}" <absolute-changed-file-paths>` — the root first so VS Code opens in the right context, then each changed file. Always double-quote paths to handle spaces and special characters.
    - If `code` is not available (command fails), skip gracefully and list the file paths instead.
 2. Display a summary in conversation output, including:
    - The commit hash (if one was created).