fix(kanban): make transition emit payload classifiable by the webhook adapter

[cwest]

Problem

The 4c transition-emit bridge POSTs a kanban lifecycle transition to the loopback webhook route (/webhooks/kanban-transition) so the orchestrator wakes as an agent run. The webhook adapter filters incoming events against the route's events allowlist, resolving the event type from — in precedence order:

X-GitHub-Event header → X-GitLab-Event header → body["event_type"] → body["type"] → "unknown"

The emitted payload carried the transition kind only as kind and in the X-Kanban-Event header — neither of which the adapter consults for classification. On a loopback POST (no GitHub/GitLab header), extraction fell through to "unknown", which is not in the route allowlist ([blocked, completed]), so the adapter returned {"status": "ignored"} with a 200 and never spawned the run.

Observed symptom (live)

kanban notifier: delivered blocked event for t_… to discord/… on board default
POST /webhooks/kanban-transition HTTP/1.1" 200
kanban transition emit: POST … -> 200 (task t_…, blocked)

— a healthy 200 on the emit, but no inbound message: platform=webhook … / agent run, unlike the github-prs route.

Root cause

Contract mismatch between the emitter and the adapter's event-extraction. The payload lacked a body field (event_type/type) the adapter reads to classify a headerless loopback POST.

Fix

Add event_type (mirroring kind) to the payload body so the adapter classifies the transition and dispatches the run. One additive key; no adapter/core change.

Tests (TDD)

• RED→GREEN unit test replicating the adapter's exact extraction precedence against the built payload: was 'unknown', now the transition kind.
• E2E HTTP proof hardened: the receiving handler now classifies the body the way the real adapter does and asserts event_type == 'blocked' — closing the gap the previous permissive dummy handler masked.
• Full emit suite green (11 passed); the touched test target passes in isolation.

Why the previous E2E test missed it

The E2E test used a dummy handler that accepted any event, so it proved the POST sent correctly but never proved the real adapter would classify and dispatch it. The hardened test now guards that wire contract.

[cwest]

The bug is real and the fix is right. I checked the adapter at head SHA d034b26: gateway/platforms/webhook.py:533-538 resolves the event type as X-GitHub-Event header, then X-GitLab-Event header, then body event_type, then body type, then "unknown", and webhook.py:540-541 drops anything not in the route's events list. The loopback emitter sends X-Kanban-Event (not consulted) and no GitHub/GitLab header, so before this change the classifier landed on "unknown" and the route returned status ignored with a 200 and never spawned a run. Adding event_type mirroring kind fills the exact slot the adapter reads, so a headerless loopback POST now classifies as its transition kind.

Ran the emit suite in a throwaway clone against the base branch (10 passed) and against the PR head (11 passed), with the added test the only difference. Then deleted the event_type key from the source and reran: both the new unit test and the hardened HTTP test fail with "adapter classified the loopback POST as 'unknown'" — the production symptom — which confirms the guard is a genuine red-to-green, not a test that passes regardless. No regressions.