Multi-milestone work and documents on the new loop (M2.4)

- Every milestone branch is cut from the latest default branch: the next
  milestone builds on the merged previous one, and a redo after a closed PR
  drops the rejected work. Uncommitted work comes along.
- While the item's PR is open, start_milestone is refused, with the PR's
  state read from Gitea at that moment, not the last watch round.
- finish_milestone(final): earlier PRs say "Part of #N", the last "Closes
  #N"; unsaid, it's final, as before.
- close_item with the item's PR still open waits for the merge (L2: a
  closed item leaves nothing open).
- The driver's instructions cover ARCHITECTURE.md and build plans under
  docs/plans/ (D2); the harness never parses a plan.
- Parking stashes uncommitted work and pushes it to <item>-parked, put back
  on resume, instead of committing it onto the item's branch. The walk
  found a half-done review fix parked onto a PR that had merged meanwhile,
  where it was lost. Architecture D4's parking line says so.

Tests: unit tests for fresh milestone branches, the merge wait (including
a merge not yet watched), redo after a closed PR, Part of/Closes, close
waiting on an open PR, and the parked-fix regression; the walk's new
milestones_start_fresh property (fork-from-current fails 9 seeds); an e2e
two-milestone feature.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE

docs/Architecture.md

@@ -670,8 +670,9 @@ Installing on any other host is dangerous.
   item ready (D5); a PR closed without merging makes it ready with that fact, and the
   agent asks what next. Redoing the milestone gets a new branch and PR, and the
   merge rule still applies to it.
-- **Parking pushes the item's branch,** so another item on the same project starts
-  fresh and this one resumes from its branch.
+- **Parking pushes the item's work:** its branch, and anything uncommitted to a side
+  branch of its own, never onto a PR's branch, which may have merged meanwhile.
+  Another item on the same project starts fresh, and this one resumes where it was.
 - **Publish only the work:** what the agent changed, counted from where the
   milestone started, never build artifacts; anything left out is reported.
 - **Pushes run on the build VM** with a push credential (a deploy key, or a

docs/Development-Plan.md

@@ -167,9 +167,22 @@ labelled and not.
   operator has spoken; `design` is steered by the driver's instructions.
 - Labels are read at intake; a label changed later is not picked up yet.
 
-**M2.4 Multi-milestone work and documents.** *Pre-approved.* Build plans in the
-repository, `ARCHITECTURE.md` kept current, waiting for merges between milestones
-(D2, D4). End-to-end: a two-milestone feature.
+**M2.4 Multi-milestone work and documents.** *Pre-approved.* **Done** (this PR).
+Build plans in the repository, `ARCHITECTURE.md` kept current, waiting for merges
+between milestones (D2, D4). End-to-end: a two-milestone feature.
+- Every milestone branch is cut from the latest default branch, so the next one
+  builds on the merged previous and a redo drops a closed PR's work. While the
+  item's PR is open, `start_milestone` is refused, the PR's state read from Gitea
+  at that moment. `finish_milestone(final)`: earlier PRs say "Part of #N", the
+  last "Closes #N".
+- `close_item` with the item's PR still open waits for the merge.
+- Documents are the driver's instructions only; the harness never parses a plan.
+- Parking stashes uncommitted work and pushes it to `<item>-parked`, put back on
+  resume, instead of committing it onto the item's branch: the walk found a
+  half-done review fix parked onto a PR that had merged meanwhile, where it was
+  lost.
+- Deferred: a milestone with no changes that wasn't expected to change code is
+  still raised with the operator (D4).
 
 **M2.5 Conversations and new projects.** *Needs discussion.* Work started in
 conversation, record issues carrying their item's ID, the new-project flow and its