Phase 0 entry gate + branch-naming convention fix

Record Phase 0 entry baseline: 820 passing, 2 pre-existing failures (Client.CLI.Tests.SubscribeCommandTests.Execute_PrintsSubscriptionMessage and Tests.MxAccess.MxAccessClientMonitorTests.Monitor_ProbeDataChange_PreventsStaleReconnect), 0 build errors, 167 build warnings. The two failures exist on v2 as of commit 1189dc8 and are unrelated to the rename. Phase 0 exit gate adapts the requirement to "failure count = baseline (2); pass count ≥ baseline (820)".

Branch-naming convention updated in implementation/overview.md and phase-0 doc: cannot use `v2/phase-N-slug` form because git treats `/` as path separator and `v2` already exists as a branch, blocking creation of any `v2/...` branch. Convention is now `phase-N-slug` (no v2/ prefix).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/v2/implementation/overview.md

@@ -142,8 +142,8 @@ Each phase produces a defined set of deliverables. The phase doc enumerates whic
 | Branch | Purpose |
 |--------|---------|
 | `v2` | Long-running design + implementation branch. All phase work merges here. |
-| `v2/phase-{N}-{slug}` | Per-phase feature branch (e.g. `v2/phase-0-rename`) |
-| `v2/phase-{N}-{slug}-{subtask}` | Per-subtask branches when the phase is large enough to warrant them |
+| `phase-{N}-{slug}` | Per-phase feature branch (e.g. `phase-0-rename`). Note: cannot use `v2/phase-...` form because git treats `/` as path separator and `v2` already exists as a branch — they would collide. |
+| `phase-{N}-{slug}-{subtask}` | Per-subtask branches when the phase is large enough to warrant them |
 
 Each phase merges to `v2` via PR after the exit gate clears. PRs include:
 - Link to the phase implementation doc