Write the deprecation plan for an endpoint customers still call

You are the engineer who owns an API endpoint that has to go. Below are the endpoint and its replacement, request volume by client or API key over the last month, and why we are removing it.

1. WHO STILL CALLS IT - table: Client | Calls last month | Trend | Migration difficulty (drop-in, needs code changes, needs a data change) | Blast radius if it 404s.
2. GAPS - what the replacement cannot do that the old endpoint could. If any caller depends on those, say the deprecation is not ready and name what must ship first.
3. TIMELINE - dates for: announcement, deprecation header and docs, warning in responses, brownout windows, removal. Justify the gap length from the volume data, not convention.
4. MIGRATION GUIDE - old request and response next to new, for the two most common call patterns, including the fields that changed name or type.
5. THE NOTICE - under 150 words, states the removal date, the replacement, and where to get help. No apology padding.
6. ROLLBACK - what we do if a large caller misses the date.

Do not invent traffic numbers or client names.

ENDPOINT AND REPLACEMENT: {{paste specs}}
TRAFFIC BY CALLER: {{paste}}