Feedback #37: Dispatch rollup marks a multi-slice brief 'complete' after one slice's dispatch closes (premature)

Implemented the dispatch rollup fix on `flower/dispatch-rollup-fix`. Change: `DispatchService::recomputeRollup()` now explicitly checks for any non-terminal dispatch request (`status` not in `done,cancelled`) before considering a brief complete. If any queued/claimed/spawned slice remains, the rollup keeps the brief `dispatched`; only when every dispatch_request is terminal and at least one completed does it mark the brief `complete`. Cancel-only rollup remains planned via the existing path. Regression coverage: added `completeForBrief` tests for a two-slice brief where the backend slice completes while the UI slice remains queued (brief stays `dispatched`), then completes when the UI slice finishes; added a single-slice `completeForBrief` test to preserve existing behavior. Verification: dispatch service/MCP tests passed (16 tests, 170 assertions); full safe sqlite suite passed with `ANTHROPIC_API_KEY=` (528 tests, 517 passed, 11 skipped, 3664 assertions); Pint passed. Commit: `ede11c2` with `Brief: #48` trailer.

Feedback #37 Authority: OPERATOR APPROVAL REQUIRED Funnel: A - operator approved brief Gate: this brief must not be dispatchable until the operator approves it. Kind: idea Source: flower-orchestrator Summary: Dispatch rollup marks a multi-slice brief 'complete' after one slice's dispatch closes (premature) Detail: Observed on Brief #22 (2026-07-01): the brief was scoped as two slices — a backend Solo-bridge dispatch + a follow-up UI dispatch. When the backend worker called brief_dispatch_complete on its dispatch (#7), the rollup rolled the WHOLE brief to `complete`, even though the UI slice + live-spawn-enable remained. The orchestrator had to manually re-open it to in_progress. So `complete` currently means 'all CURRENTLY-OPEN dispatches are done', not 'the brief's scope is done'. Ideas: (a) a worker completing a dispatch should default the brief to in_progress (not complete) unless it's the final slice; (b) let the completer signal 'brief still has scope' vs 'brief done'; (c) model each dispatchable slice as its own brief so `complete` is accurate; (d) a brief flag like `expects_more_dispatches`. Ties to the operator's closeout-hygiene concern: a brief reading 'complete' while work remains is exactly the kind of false-done we want to avoid. Not blocking (re-open works) but worth a small rollup-semantics fix. Context JSON: { "brief": 22, "observed": "brief auto-completed after backend slice; UI + enable-live-spawn remain", "workaround": "orchestrator re-opened to in_progress", "dispatch_request": 7 }