Epic-lead Slice D — Epic-branch merge + baton coexistence (#226)

You are being dispatched from flower Brief #234: Epic-lead Slice D — Epic-branch merge + baton coexistence (#226)

Recall pointer:
- Use recall_brief with id 234 for the full folder if you need provenance.

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/234-epic-lead-slice-d
- worktree: not specified
- kind: fresh

Current brief spec:
# Slice D — Epic-branch merge + baton coexistence

Parent epic: #226. Design: `docs/design/226-epic-lead-orchestration.md` (§Baton & merge, §Worktree). **Depends on Slice C (#233).** Target ≤~300 lines. Honors decided fork **#55**.

## Deliverable
1. **Child → epic-branch merge discipline** — the lead merges `flower/epic-<id>-<child>` → `flower/epic-<id>` inside its epic worktree, guarded by an **epic-branch-scoped Solo lock** `mcp__solo__lock_acquire('flower-epic-<id>-merge')` — a distinct namespace from the MAIN baton (`Setting daemon_reset.active_orchestrator_daemon_id`). These never reach master, so they need no baton. (Mostly charter/convention text + a small guard/helper; the lead is the sole writer of its epic branch.)
2. **The single MAIN merge** — when the epic branch is whole (all children merged + epic-branch suite green), the lead enqueues `epic_return{action:merge}`; MAIN, under the baton, does the one `git merge --no-edit flower/epic-<id>` → master from the MAIN checkout per the existing merge protocol (clean tree → merge → keep all FoundationTest tables → migrate → full suite → verify on real MySQL). Then MAIN `epic_delegate{action:merged}` back.
3. **Baton invariant preserved** — assert/verify the lead never triggers a master merge and never holds the baton; the baton's authority over master merges is untouched. The invariant is convention-enforced (`assertCanDrainOrMerge` is dead code) — the change is charter prose + confirming no code path lets a lead merge to master.
4. **Child dispatch scoping** — the lead uses **direct/lead-mediated dispatch** (out of the project `auto_max_concurrent` accounting, which is per-project + keyed on `recommended->auto_dispatch->signal_kind`) with its own `config('flower.epic_lead.max_concurrent', 3)` fan-out cap. Reviews via `brief_request_review`/`brief_review` (`ReviewService` auto-bounce). Respects `brief_depend` gating on children.

## Tests
- Baton assertions unaffected by a live lead.
- `epic_return{merge}` routes to MAIN's merge path; the epic-lock namespace is disjoint from the baton.
- Lead child dispatch does not increment the project auto-dispatch concurrency count.

## Notes
- No new git-merge *service* — MAIN merges by hand per charter, as today; this slice defines the epic-branch target + the handoff, not a merge automation.

Recent/key trace events:
[1] participant_joined flower-226-worker: (no body)
[2] note_added flower-226-worker: # Slice D — Epic-branch merge + baton coexistence

Design: `docs/design/226-epic-lead-orchestration.md` (§Baton & merge, §Worktree). Depends on Slice C. Target ≤~300 lines. Honors decided fork **#55**.

## Deliverable
1. **Child → epic-branch merge discipline** — the lead merges `flower/epic-<id>-<child>` → `flower/epic-<id>` inside its epic worktree, guarded by an **epic-branch-scoped Solo lock** `mcp__solo__lock_acquire('flower-epic-<id>-merge')` — a distinct namespace from the MAIN baton (`Setting daemon_reset.active_orchestrator_daemon_id`). These never reach master, so they need no baton. (Mostly charter/convention text + a small guard/helper; the lead is the sole writer of its epic branch.)
2. **The single MAIN merge** — when the epic branch is whole (all children merged + epic-branch suite green), the lead enqueues `epic_return{action:merge}`; MAIN, under the baton, does the one `git merge --no-edit flower/epic-<id>` → master from the MAIN checkout per the existing merge protocol (clean tree → merge → keep all FoundationTest tables → migrate → full suite → verify on real MySQL). Then MAIN `epic_delegate{action:merged}` back.
3. **Baton invariant preserved** — assert/verify the lead never triggers a master merge and never holds the baton; the baton's authority over master merges is untouched. The invariant is convention-enforced (`assertCanDrainOrMerge` is dead code) — the change is charter prose + confirming no code path lets a lead merge to master.
4. **Child dispatch scoping** — the lead uses **direct/lead-mediated dispatch** (out of the project `auto_max_concurrent` accounting, which is per-project + keyed on `recommended->auto_dispatch->signal_kind`) with its own `config('flower.epic_lead.max_concurrent', 3)` fan-out cap. Reviews via `brief_request_review`/`brief_review` (`ReviewService` auto-bounce). Respects `brief_depend` gating on children.

## Tests
- Baton assertions unaffected by a live lead.
- `epic_return{merge}` routes to MAIN's merge path; the epic-lock namespace is disjoint from the baton.
- Lead child dispatch does not increment the project auto-dispatch concurrency count.

## Notes
- No new git-merge *service* — MAIN merges by hand per charter, as today; this slice defines the epic-branch target + the handoff, not a merge automation.
[3] parent_set flower-226-worker: Grouped under epic #226.
[4] dependency_added flower-226-worker: Now depends on #233 (Epic-lead Slice C — Coordination signals epic_delegate / epic_return (#226)).
[5] plan_proposed flower-226-worker: # Slice D — Epic-branch merge + baton coexistence

Parent epic: #226. Design: `docs/design/226-epic-lead-orchestration.md` (§Baton & merge, §Worktree). **Depends on Slice C (#233).** Target ≤~300 lines. Honors decided fork **#55**.

## Deliverable
1. **Child → epic-branch merge discipline** — the lead merges `flower/epic-<id>-<child>` → `flower/epic-<id>` inside its epic worktree, guarded by an **epic-branch-scoped Solo lock** `mcp__solo__lock_acquire('flower-epic-<id>-merge')` — a distinct namespace from the MAIN baton (`Setting daemon_reset.active_orchestrator_daemon_id`). These never reach master, so they need no baton. (Mostly charter/convention text + a small guard/helper; the lead is the sole writer of its epic branch.)
2. **The single MAIN merge** — when the epic branch is whole (all children merged + epic-branch suite green), the lead enqueues `epic_return{action:merge}`; MAIN, under the baton, does the one `git merge --no-edit flower/epic-<id>` → master from the MAIN checkout per the existing merge protocol (clean tree → merge → keep all FoundationTest tables → migrate → full suite → verify on real MySQL). Then MAIN `epic_delegate{action:merged}` back.
3. **Baton invariant preserved** — assert/verify the lead never triggers a master merge and never holds the baton; the baton's authority over master merges is untouched. The invariant is convention-enforced (`assertCanDrainOrMerge` is dead code) — the change is charter prose + confirming no code path lets a lead merge to master.
4. **Child dispatch scoping** — the lead uses **direct/lead-mediated dispatch** (out of the project `auto_max_concurrent` accounting, which is per-project + keyed on `recommended->auto_dispatch->signal_kind`) with its own `config('flower.epic_lead.max_concurrent', 3)` fan-out cap. Reviews via `brief_request_review`/`brief_review` (`ReviewService` auto-bounce). Respects `brief_depend` gating on children.

## Tests
- Baton assertions unaffected by a live lead.
- `epic_return{merge}` routes to MAIN's merge path; the epic-lock namespace is disjoint from the baton.
- Lead child dispatch does not increment the project auto-dispatch concurrency count.

## Notes
- No new git-merge *service* — MAIN merges by hand per charter, as today; this slice defines the epic-branch target + the handoff, not a merge automation.
[6] participant_joined flower-233-worker: (no body)
[7] unblocked flower-233-worker: Unblocked — #233 reached complete.
[8] participant_joined flower-orchestrator: (no body)
[9] status_change flower-orchestrator: (no body)

Recommended linked context:
{
    "todos": [],
    "scratchpads": []
}

Execution notes:
- Treat the brief as the source of truth.
- Keep work scoped to this dispatch request.
- Use brief_append / brief_update_status when reporting material progress; as your final dispatched-worker step, call brief_dispatch_complete with dispatch_request_id (or brief_id) and actor_ref.
- Codex workers should verify mutating Flower tools with tool_search query `brief_append brief_dispatch_complete flower_feedback` (limit 20) when tool availability is in doubt; report raw SEE/LOAD vs NOT visible instead of silently using local fallbacks.
- Add a git commit trailer `Brief: #234` to every commit for this brief so flower can exact-link commits back to the brief.