Feedback #77: brief_claim/brief_dispatch responses triple-embed the dispatch packet → MCP token overflow

You are being dispatched from flower Brief #171: Feedback #77: brief_claim/brief_dispatch responses triple-embed the dispatch packet → MCP token overflow

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

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/77-dispatch-packet-dedup
- worktree: not specified
- kind: fresh

Current brief spec:
(no spec yet)

This is a direct request, not a fully-specced plan. If it's clear, resolve it. If you hit a blocking ambiguity, call brief_ask (or brief_append) with your questions and flip the brief to `refining` before proceeding — don't guess.

Recent/key trace events:
[1] participant_joined flower-orchestrator: (no body)
[2] note_added flower-orchestrator: ## Bug (feedback #77, reported by the #36 worker; hit twice by the orchestrator this session)
`brief_claim` / `brief_dispatch` MCP tool responses embed the fully-rendered dispatch packet **three times** — top-level `packet`, top-level `instructions`, and `request.prompt` — plus `request.recommended`. On a heavy brief (long spec + many trace events) this triples an already-large payload past the MCP token cap: `brief_claim(36)` returned 71,598 chars and spilled to a file, so the ack couldn't be read inline. Confirmed to also hit `brief_dispatch` (the #36 and #144 dispatch acks both spilled this session).

## Fix
Return a **compact ack by default** from the mutating dispatch tools (`brief_dispatch`, `brief_claim`, and any sibling that renders the packet). The ack should carry only the small structured fields a caller needs — `dispatched`/`claimed`, `request.id`/`status`/`brief_id`/`target_branch`/`agent_tool` — and must NOT embed the full rendered packet multiple times.
- De-duplicate: the packet content should appear **at most once** (e.g. keep `request.prompt` only, or put the packet behind an opt-in flag / a follow-up read), with `packet`/`instructions` reduced to short pointers if kept at all.
- Audit ALL `brief_*` MCP tools + the shared packet-rendering / serializer path (BriefDispatchTool, BriefClaimTool, and whatever renders the packet) for the same triple-embedding.
- Preserve worker-facing info: a dispatched/claimed worker must still be able to obtain its full packet (`recall_brief(N)` already returns fine inline, so a pointer to that is acceptable).
- Keep it backward-tolerant for the orchestrator's manual-dispatch flow, which reads `request.id` + `status`.

## Acceptance
- `brief_dispatch` + `brief_claim` acks stay well under the MCP token cap on the heaviest briefs (no spill-to-file); packet content is not duplicated.
- Feature tests asserting the compact ack shape for both tools. `php artisan test` green + pint. `Brief: #<this>` trailer. Mark feedback #77 addressed when the fix lands.

## Provenance
flower feedback #77 (mcp_issue, source flower-36), routed funnel-B by flower-ops → fix-spec Solo scratchpad 1069 / todo 384 / coordination signal 45. Operator flagged 2026-07-04 as an ASAP open-worktree fix.
[3] 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: #171` to every commit for this brief so flower can exact-link commits back to the brief.