On a Brief's detail view - if it's in markdown it's hard to read for m

You are being dispatched from flower Brief #81: On a Brief's detail view - if it's in markdown it's hard to read for m

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

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/81-markdown-editor
- worktree: not specified
- kind: fresh

Current brief spec:
## Ask
Brief spec/body content is often markdown but is shown/edited in a plain textarea, which is hard to read. Add a markdown editor that supports a **raw ⇄ rendered** toggle so the operator can read the rendered version and edit the raw source.

## Scope (canonical markdown-editor brief — covers both surfaces)
This is the single home for the markdown-editor request. It covers TWO mount points that share one component:
1. **Brief detail view** — the spec editor (`resources/views/livewire/briefs/*` / the brief detail Livewire component). Primary ask (this brief's origin).
2. **`/briefs` create form textarea** — folded in from Brief #87 item 2 (same editor component; keep #87 focused on the other roster/form items).

## Requirements
- A markdown-aware editor component with a **raw source** mode (editable textarea) and a **rendered preview** mode (read-only formatted), toggled by a control. Either a side-by-side split or a raw/preview toggle is acceptable — pick what fits the bloom design system; a toggle is the simpler v1.
- Rendered markdown must match the app's existing markdown rendering (reuse whatever the app already uses to render markdown elsewhere; if none, use a single shared renderer — e.g. league/commonmark server-side or a small client-side lib — and centralize it so both mount points share it).
- Editing still writes the raw markdown back through the existing Livewire save path (`brief_update_spec` equivalent in the UI); no change to stored format (raw markdown in the DB).
- Match the dark "bloom" design system (`resources/views/components/ui/*`), FluxUI where it fits.

## Stretch (do NOT block v1)
- Inline image paste (copy/paste screenshots) on the create form (Brief #87 item 2's secondary ask). Requires an image store + upload path — capture as a follow-up if not trivial.

## Acceptance
- On a brief with markdown spec, the operator can toggle between readable rendered output and editable raw source, and edits persist.
- Same component works on the `/briefs` create textarea.
- `php artisan test` green; `./vendor/bin/pint` clean; verify in the real app (Livewire) not just tests.

## Notes / links
- Subsumes Brief #87 item 2. Related to #87 (the rest of the /briefs + /roster UI cluster).
- Add commit trailer `Brief: #81`.

Recent/key trace events:
[1] participant_joined operator:mike: (no body)
[2] note_added operator:mike: On a Brief's detail view - if it's in markdown it's hard to read for me in the vanilla textarea - can get integrate a markdown editor here so that it's viewable via raw or via rendered?
[3] status_change operator:mike: (no body)
[4] participant_joined flower-orchestrator: (no body)
[5] spec_snapshot flower-orchestrator: On a Brief's detail view - if it's in markdown it's hard to read for me in the vanilla textarea - can get integrate a markdown editor here so that it's viewable via raw or via rendered?
[6] refinement flower-orchestrator: ## Ask
Brief spec/body content is often markdown but is shown/edited in a plain textarea, which is hard to read. Add a markdown editor that supports a **raw ⇄ rendered** toggle so the operator can read the rendered version and edit the raw source.

## Scope (canonical markdown-editor brief — covers both surfaces)
This is the single home for the markdown-editor request. It covers TWO mount points that share one component:
1. **Brief detail view** — the spec editor (`resources/views/livewire/briefs/*` / the brief detail Livewire component). Primary ask (this brief's origin).
2. **`/briefs` create form textarea** — folded in from Brief #87 item 2 (same editor component; keep #87 focused on the other roster/form items).

## Requirements
- A markdown-aware editor component with a **raw source** mode (editable textarea) and a **rendered preview** mode (read-only formatted), toggled by a control. Either a side-by-side split or a raw/preview toggle is acceptable — pick what fits the bloom design system; a toggle is the simpler v1.
- Rendered markdown must match the app's existing markdown rendering (reuse whatever the app already uses to render markdown elsewhere; if none, use a single shared renderer — e.g. league/commonmark server-side or a small client-side lib — and centralize it so both mount points share it).
- Editing still writes the raw markdown back through the existing Livewire save path (`brief_update_spec` equivalent in the UI); no change to stored format (raw markdown in the DB).
- Match the dark "bloom" design system (`resources/views/components/ui/*`), FluxUI where it fits.

## Stretch (do NOT block v1)
- Inline image paste (copy/paste screenshots) on the create form (Brief #87 item 2's secondary ask). Requires an image store + upload path — capture as a follow-up if not trivial.

## Acceptance
- On a brief with markdown spec, the operator can toggle between readable rendered output and editable raw source, and edits persist.
- Same component works on the `/briefs` create textarea.
- `php artisan test` green; `./vendor/bin/pint` clean; verify in the real app (Livewire) not just tests.

## Notes / links
- Subsumes Brief #87 item 2. Related to #87 (the rest of the /briefs + /roster UI cluster).
- Add commit trailer `Brief: #81`.
[7] participant_joined flower-refine: (no body)
[8] refinement flower-refine: flower-refine review: spec is complete and build-ready — clear Ask / Scope (two mount points sharing one component: brief-detail spec editor + /briefs create textarea) / Requirements (raw⇄rendered toggle, reuse existing markdown renderer or centralize one, raw markdown stays the stored format) / Acceptance, with inline image paste correctly deferred to Stretch (non-blocking). No open questions remain. Moving to `planned` (dispatch-ready). Subsumes #87 item [2]; keep #87 focused on the other /briefs + /roster items.
[9] status_change flower-refine: (no body)
[10] link_added flower-orchestrator: (no body)

Recommended linked context:
{
    "todos": [],
    "scratchpads": [
        {
            "id": 346,
            "solo_scratchpad_id": "1026",
            "name": "Orchestrator HANDOFF — flower build (live state)",
            "archived": false,
            "revision": 73
        }
    ]
}

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: #81` to every commit for this brief so flower can exact-link commits back to the brief.