spec: document git worktree sandbox apply strategy (AUTO-ARCH-7)

Updates the Apply phase section to reflect the implementation upgrade
from flat shutil.copy2 to git worktree merge strategy. Documents
fallback behavior for non-git projects and Apply Summary output format.

Closes #8788

docs/specification.md

@@ -19873,6 +19873,63 @@ Apply should perform (configurable) validations before committing:
 
   * Record who applied, what changed, when, and why.
 
+#### Apply Strategy: Git Worktree Merge
+
+The `plan apply` command uses a **git worktree merge strategy** as its primary mechanism for committing LLM-generated changes from the sandbox into the real project.
+
+##### Primary Strategy: Git Worktree Merge (Git Projects)
+
+For projects backed by a git resource (`git-checkout` or `git` resource type), Apply merges changes via `git merge` from the isolated worktree branch into the project main branch:
+
+1. **Isolated execution**: During Execute, all mutations are confined to a dedicated git worktree branch (e.g., `.worktrees/plan-<PLAN_ID>`). The worktree is created at plan start and acts as the sandbox.
+2. **Merge on apply**: When `plan apply` is invoked, the system performs a `git merge` from the worktree branch into the target branch (typically `main`). This preserves full git history and enables standard conflict detection.
+3. **Conflict detection**: If the merge produces conflicts that violate invariants or cannot be auto-resolved, the plan enters the `constrained` terminal state. The sandbox worktree is preserved for inspection or correction.
+4. **Sandbox cleanup**: After a successful merge, the worktree is removed and the worktree branch is deleted. The `Sandbox Cleanup` panel in the Apply output confirms: `Worktree: removed`, `Branch: merged to main`, `Checkpoint: archived`.
+
+This approach preserves git history, enables standard conflict detection, and integrates naturally with existing git workflows.
+
+##### Fallback Strategy: Flat File Copy (Non-Git Projects)
+
+For projects that are **not** backed by a git resource (e.g., `fs-mount` or `fs-directory` resources without an underlying git repository), Apply falls back to a flat file copy using `shutil.copy2`. In this mode:
+
+* Each artifact produced during Execute is copied directly from the sandbox directory to the real project path.
+* No merge conflict detection is performed; the sandbox files overwrite the destination.
+* The sandbox directory is cleaned up after the copy completes.
+
+The fallback is selected automatically based on whether the project primary resource is a git-managed checkout.
+
+##### Apply Summary Output
+
+After a successful apply, the CLI displays a spec-aligned **Apply Summary** panel followed by a **Sandbox Cleanup** panel and a `✓ OK Changes applied` footer:
+
+```
+Apply Summary
+  Plan:       <PLAN_ID>
+  Artifacts:  <N> files updated
+  Changes:    <insertions> insertions, <deletions> deletions
+  Project:    <project-name>
+  Applied At: <YYYY-MM-DD HH:MM>
+
+Sandbox Cleanup
+  Worktree:   removed
+  Branch:     merged to main
+  Checkpoint: archived
+
+✓ OK  Changes applied
+```
+
+The Apply Summary fields are:
+
+| Field | Description |
+|-------|-------------|
+| `Plan` | The ULID plan identifier |
+| `Artifacts` | Number of files updated by the apply |
+| `Changes` | Insertions and deletions from the git diff (git projects) or file count (non-git fallback) |
+| `Project` | The namespaced project name |
+| `Applied At` | Timestamp of the apply operation |
+
+The Sandbox Cleanup panel reflects the post-apply state of the worktree, branch, and checkpoint. For non-git fallback applies, the `Branch` field is omitted.
+
 #### Validation in Apply
 
 Validation runs during **Execute**, not during Apply. By the time a plan reaches the Apply phase, all required validations have already passed. Apply commits the sandbox changes to the real resources and does not re-run validations.