fix: from-template booking has no idempotency lookup #87

Symptom

POST /api/v1/deals/from-template accepts idempotency_key but neither the route handler nor deal_service.create_deal_from_template ever reads it. A client retry with the same key creates a second deal with a new id.

Once #85 lands, the retry also publishes a second deal.created event, which is how this became visible.

Reproduction

Two identical requests from an authenticated agency buyer, same idempotency_key, against an empty in-memory store with a one-product catalog:

call 1: POST /api/v1/deals/from-template {"idempotency_key": "probe-tpl-1", "deal_type": "PD", "product_id": "ctv-premium-sports", "impressions": 1000000}  -> 201 DEMO-877AACB4E7B1
call 2: same body                                                                                                                                              -> 201 DEMO-7A1BF3178B08
stored deals: 2    idempotency records stored: 0

Two distinct deal ids from one logical request. No idempotency: key is ever written, so nothing to replay against; the key is accepted by the request model and then ignored.

Environment

seller-agent main at 8dfd5e0 (after #78), installed with uv sync --locked: Python 3.12.12, fastapi 0.139.0, iab-agentic-primitives==0.5.1. macOS 26.6. Reproduced in-process against the FastAPI app through httpx.ASGITransport, storage replaced by an in-memory double, so the numbers above are what the routes return, not what an ad server does.

Context

This is the remaining sibling of a series already fixed one route at a time: #44 (quotes), #51 (negotiation messages), #62 (change requests). POST /api/v1/deals has the lookup and the conflict detection from #50; this route sits in the same file and should share it.

Expected

Same key and same payload replay the original deal; same key and a different payload return 409 idempotency_conflict; the key is scoped per verified buyer as on the quote-booking route.

Pre-existing on main at 8dfd5e0.