mcp-tool-drift: gate validation-brief creation on discovery materiality (stop none/none noise)

You are being dispatched from flower Brief #161: mcp-tool-drift: gate validation-brief creation on discovery materiality (stop none/none noise)

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

Target:
- project: flower (/Users/mikeferrara/Documents/code/flower)
- branch: flower/161-mcp-drift-materiality-gate
- worktree: not specified
- kind: fresh

Current brief spec:
## Objective
Stop `flower:mcp-tool-drift` from creating cross-harness validation briefs on **description/schema-only** MCP tool changes, and make any brief it *does* create show the **actual** delta. Gate brief creation on **discovery-materiality**, not the raw full-definition hash.

## Problem (grounded in code, 2026-07-03)
- `App\Services\Mcp\McpToolSetSnapshot::capture()` hashes `sha256` over the JSON of each tool's **full canonicalized definition** — name + description + input schema — with tools sorted by name and keys recursively `ksort`ed. So it is **deterministic** (identical tools → identical hash; not spurious churn).
- `App\Console\Commands\McpToolDriftCommand::handle()` creates a validation brief whenever `previousHash !== currentHash`.
- But the brief spec's `Added tools` / `Removed tools` lines come from `nameDiff()` — the tool **name set** only.
- ⇒ Editing any tool's **description or input schema** flips the hash while names are unchanged → a brief is created reading **"Added: none, Removed: none."** It looks spurious, but a definition genuinely changed — it's just never shown.
- Evidence: #65 (`20a663fa → 3fea07f5`, count 41, names identical) plus the abandon pile **#44 / #65 / #83 / #113** (5 of 6 drift briefs abandoned or cancelled). Description/schema-only edits don't affect cross-harness **discovery** (same names, same `tools/list` page-1 membership), so these briefs are low value.
- Source: `flower_feedback` bug **#73** + operator request.

## Change (thin)
1. **Decouple "hash changed" from "create a brief."** Keep hashing the full definition as the snapshot key (so every change is still recorded in the `mcp.toolset.snapshot` Setting), but only **create a validation brief** when the change is **discovery-material**:
   - a tool **name** is added or removed, **OR**
   - the **first-page composition of `tools/list` changes** such that any mutating tool (`brief_append`, `brief_dispatch_complete`, `flower_feedback`) could move on/off page 1 — reuse the first-page assertion already built in `App\Services\Mcp\McpToolValidationService` (Brief #40).
   - Description/schema-only changes with unchanged names **and** unchanged page-1 membership → **update the snapshot only** (optionally log to console/a Setting), **no brief**.
2. **Always show the real delta.** When a brief *is* created, its spec must report what actually changed: name adds/removes **plus** a "definitions changed: `x`, `y`" list (derive per-tool definition hashes from the `tools` array already persisted in the snapshot). Never emit a misleading `none/none`.
3. Preserve the existing `--force` behavior (create a brief even when unchanged) and `--dry-run`.

## Grounding / reuse
- `McpToolValidationService` (Brief #40, already merged) computes the tool set + hash + first-page-completeness assertion → reuse it for the materiality check rather than re-deriving it.
- The snapshot Setting `mcp.toolset.snapshot` already persists `tools` (full per-tool arrays) + `names`, so a per-tool definition diff is computable from stored state.

## Acceptance
- Description/schema-only tool change (names + page-1 membership unchanged) → **no brief**; snapshot updated. Test asserts this (e.g. synthetic description edit).
- A tool name added/removed **OR** a mutating tool crossing the page-1 boundary → **brief created** with an accurate delta (names + changed-definition list); never `none/none`. Tests for both.
- `--force` still creates a brief; `--dry-run` unchanged. `php artisan test` green + `./vendor/bin/pint` on touched files. Commit trailer `Brief: #161`.

## Non-goals / relationships
- Does **not** build the deferred v2 per-harness agent automation (that's Brief #40 v2, which depends on #36's delivery decision).
- Reinforces the auto-dispatch decision: these validation briefs stay **non-auto-dispatch**; this change removes the noise that made blanket auto-dispatch a bad idea.

## Definition of done
The drift detector only briefs on discovery-material changes and always shows the real delta; tests + pint green; ready for dispatch.

Recent/key trace events:
[1] participant_joined flower-refine: (no body)
[2] note_added flower-refine: From flower_feedback bug #73 + operator request (2026-07-03). The scheduled flower:mcp-tool-drift detector creates cross-harness validation briefs on description/schema-only tool edits (name set unchanged), displayed misleadingly as "Added/Removed: none" — noise that fills the abandon pile. Gate brief creation on discovery-materiality and always show the real delta.
[3] plan_proposed flower-refine: ## Objective
Stop `flower:mcp-tool-drift` from creating cross-harness validation briefs on **description/schema-only** MCP tool changes, and make any brief it *does* create show the **actual** delta. Gate brief creation on **discovery-materiality**, not the raw full-definition hash.

## Problem (grounded in code, 2026-07-03)
- `App\Services\Mcp\McpToolSetSnapshot::capture()` hashes `sha256` over the JSON of each tool's **full canonicalized definition** — name + description + input schema — with tools sorted by name and keys recursively `ksort`ed. So it is **deterministic** (identical tools → identical hash; not spurious churn).
- `App\Console\Commands\McpToolDriftCommand::handle()` creates a validation brief whenever `previousHash !== currentHash`.
- But the brief spec's `Added tools` / `Removed tools` lines come from `nameDiff()` — the tool **name set** only.
- ⇒ Editing any tool's **description or input schema** flips the hash while names are unchanged → a brief is created reading **"Added: none, Removed: none."** It looks spurious, but a definition genuinely changed — it's just never shown.
- Evidence: #65 (`20a663fa → 3fea07f5`, count 41, names identical) plus the abandon pile **#44 / #65 / #83 / #113** (5 of 6 drift briefs abandoned or cancelled). Description/schema-only edits don't affect cross-harness **discovery** (same names, same `tools/list` page-1 membership), so these briefs are low value.
- Source: `flower_feedback` bug **#73** + operator request.

## Change (thin)
1. **Decouple "hash changed" from "create a brief."** Keep hashing the full definition as the snapshot key (so every change is still recorded in the `mcp.toolset.snapshot` Setting), but only **create a validation brief** when the change is **discovery-material**:
   - a tool **name** is added or removed, **OR**
   - the **first-page composition of `tools/list` changes** such that any mutating tool (`brief_append`, `brief_dispatch_complete`, `flower_feedback`) could move on/off page 1 — reuse the first-page assertion already built in `App\Services\Mcp\McpToolValidationService` (Brief #40).
   - Description/schema-only changes with unchanged names **and** unchanged page-1 membership → **update the snapshot only** (optionally log to console/a Setting), **no brief**.
2. **Always show the real delta.** When a brief *is* created, its spec must report what actually changed: name adds/removes **plus** a "definitions changed: `x`, `y`" list (derive per-tool definition hashes from the `tools` array already persisted in the snapshot). Never emit a misleading `none/none`.
3. Preserve the existing `--force` behavior (create a brief even when unchanged) and `--dry-run`.

## Grounding / reuse
- `McpToolValidationService` (Brief #40, already merged) computes the tool set + hash + first-page-completeness assertion → reuse it for the materiality check rather than re-deriving it.
- The snapshot Setting `mcp.toolset.snapshot` already persists `tools` (full per-tool arrays) + `names`, so a per-tool definition diff is computable from stored state.

## Acceptance
- Description/schema-only tool change (names + page-1 membership unchanged) → **no brief**; snapshot updated. Test asserts this (e.g. synthetic description edit).
- A tool name added/removed **OR** a mutating tool crossing the page-1 boundary → **brief created** with an accurate delta (names + changed-definition list); never `none/none`. Tests for both.
- `--force` still creates a brief; `--dry-run` unchanged. `php artisan test` green + `./vendor/bin/pint` on touched files. Commit trailer `Brief: #161`.

## Non-goals / relationships
- Does **not** build the deferred v2 per-harness agent automation (that's Brief #40 v2, which depends on #36's delivery decision).
- Reinforces the auto-dispatch decision: these validation briefs stay **non-auto-dispatch**; this change removes the noise that made blanket auto-dispatch a bad idea.

## Definition of done
The drift detector only briefs on discovery-material changes and always shows the real delta; tests + pint green; ready for dispatch.
[4] status_change flower-refine: (no body)
[5] link_added flower-refine: (no body)

Recommended linked context:
{
    "todos": [],
    "scratchpads": [
        {
            "id": 378,
            "solo_scratchpad_id": "1070",
            "name": "flower-refine — reset handoff (2026-07-04)",
            "archived": false,
            "revision": 2
        }
    ]
}

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