Push notifications: config accepted but webhook never delivered on task completion

[mabry1985]

Symptom

Workstacean registers a push-notification callback via `tasks/pushNotificationConfig/set` — Quinn accepts (no error). But when the task reaches terminal state, Quinn never POSTs to the callback URL. Workstacean falls back to polling (30s cadence) to detect completion.

Compare with the researcher agent which now delivers via webhook:
```

Researcher ✅

[task-tracker] Callback for e414b4c8… → terminal state "completed" (via webhook)

Quinn ❌

[task-tracker] Task 513e2950… reached terminal state "completed" after 36s
```

What needs to happen

On terminal state transition (`completed`, `failed`, `canceled`), Quinn should:

1. Check if a `pushNotificationConfig` exists for the task
2. POST the full Task JSON to `config.url` with `Authorization: Bearer <config.token>`
3. Fire-and-forget (retain the `asyncio.Task` handle per the hardening guide — weak ref GC trap)
4. Retry once on transient failure (network blip); drop on 4xx

Reference: Build an A2A Agent — Push notifications and Task store hardening #2.

Impact

Without webhook delivery, every Quinn task uses 30s-cadence polling. Functional but adds 15s average latency to result delivery and burns polling round-trips that push eliminates.

[mabry1985]

Resolved in #62 (v0.1.8 — live)

Root cause: visibility, not delivery

Quinn's webhook delivery code was firing correctly the whole time. The problem was that every logger.info in a2a_handler.py — including "push config registered" and "webhook delivered" — was silently filtered: server.py never called logging.basicConfig, so Python's default WARNING threshold was in effect. Only logger.warning / logger.error ever reached docker logs (the two DNS blips at 02:16 UTC being the only evidence delivery was even attempting).

What shipped in #62

1. server.py installs logging.basicConfig(level=INFO) at module import (LOG_LEVEL env var overrides).
2. _deliver_webhook success log upgraded DEBUG → INFO, with task id + state + URL for grep.
3. JSON-RPC pushNotificationConfig/set handler gets the "push config registered" INFO line the REST alias has had since fix(a2a): canceled webhooks, atomic cancel, webhook retention, SSRF guard #19.
4. Bonus spec fix: JSON-RPC message/send now returns kind: "task" via _task_to_response() like every other Task-returning path. The inline dict had omitted it — would have tripped @a2a-js/sdk's client routing sooner or later.

Verified live

Submitted a test task + registered a push config, watched the new INFO lines land:

2026-04-17 05:20:58 INFO a2a_handler [a2a] push config registered (jsonrpc)
                       task=747ab498-93b5-4799-8bf1-b006b5c7c7d6 state=working
                       → http://workstacean:3000/api/a2a/callback/747ab498-...
2026-04-17 05:21:03 INFO a2a_handler [a2a] webhook delivered
                       task=747ab498-... state=completed
                       → http://workstacean:3000/api/a2a/callback/747ab498-... (404)

The 404 is expected for that test — I dispatched directly rather than via Workstacean's SkillDispatcher, so Workstacean's TaskTracker didn't know about the taskId and correctly rejected the callback at a2a-callback.ts:43-45.

For real Workstacean → Quinn dispatches

Expected path now shows both log lines on every dispatch:

• push config registered (jsonrpc) task=... → http://workstacean:3000/api/a2a/callback/...
• webhook delivered task=... state=completed → ... (200) ← should be 200 for real dispatches because Workstacean's TaskTracker tracks the taskId at dispatch time

If you see (404) on a Workstacean-dispatched task, that's a TaskTracker-registration race at Workstacean. If you see (401), that's a token mismatch. Either is a Workstacean follow-up with concrete evidence instead of silence.

Closing as completed.