feat(quick-dev): add previous story continuity to context loading

When quick-dev infers the intent is an epic story, it now scans for
completed specs from the same epic and loads the most recent one to
extract Code Map, Design Notes, Spec Change Log, and task list as
continuity context for planning.

src/bmm-skills/4-implementation/bmad-quick-dev/step-01-clarify-and-route.md

@@ -49,6 +49,12 @@ Never ask extra questions if you already understand what the user intends.
      - **Epics** (`*epic*`) — feature breakdown into implementable stories
      - **Product Brief** (`*brief*`) — project vision and scope
    - Scan the listing for files matching these patterns. If any look relevant to the current intent, load them selectively — you don't need all of them, but you need the right constraints and requirements rather than guessing from code alone.
+   - **Previous story continuity.** Using the intent and loaded context (especially any epics file), infer whether the current work is a story from an epic. Do not rely on filename patterns or regex — reason about the intent, the artifact listing, and epics content together. If the intent is an epic story:
+     1. Identify the epic and story number.
+     2. Scan `{implementation_artifacts}` for specs from the same epic with `status: done` and a lower story number.
+     3. Load the most recent one (highest story number below current).
+     4. Extract its **Code Map**, **Design Notes**, **Spec Change Log**, and **task list** as continuity context for step-02 planning.
+     If no `done` spec is found but an `in-review` spec exists for the same epic with a lower story number, note it to the user and ask whether to load it. If the intent is not an epic story, or no previous spec exists, skip this silently.
 2. Clarify intent. Do not fantasize, do not leave open questions. If you must ask questions, ask them as a numbered list. When the human replies, verify that every single numbered question was answered. If any were ignored, HALT and re-ask only the missing questions before proceeding. Keep looping until intent is clear enough to implement.
 3. Version control sanity check. Is the working tree clean? Does the current branch make sense for this intent — considering its name and recent history? If the tree is dirty or the branch is an obvious mismatch, HALT and ask the human before proceeding. If version control is unavailable, skip this check.
 4. Multi-goal check (see SCOPE STANDARD). If the intent fails the single-goal criteria: