Find out if a release drove up Zendesk tickets

**Objective:** Measure the support impact of release `{app-version}` of Bugsnag project `{project-name}`, comparing Zendesk tickets in the `{window-days}` days (default 7) either side of the release.

**Step 1: Find the release**

Call `bugsnag-get-release` with `project-name` set to `{project-name}` and `app-version` set to `{app-version}`, filtering `release-stage` to production. If `{app-version}` is empty, call it with `project-name` only and take the most recent production release by release-date. If nothing comes back, list the project's recent releases and stop.

Note the release-date, errors-introduced-count, errors-seen-count and unhandled-sessions-count.

**Step 2: Find what the release broke**

Call `bugsnag-get-event` with `app-version` set to the release's app-version and `received.from` set to the release-date. Group the events by error-id and keep the errors with the most events (up to 10). For each, call `bugsnag-get-error` with that error-id and keep the errors whose first-seen-date is on or after the release-date; those are new in this release.

**Step 3: Compare ticket volume**

Call `zendesk-get-ticket` twice: once with `created.from` = release-date minus `{window-days}` days and `created.to` = the day before the release-date, and once with `created.from` = release-date and `created.to` = release-date plus `{window-days}` days. Count tickets in each window, overall and by type and priority.

**Step 4: Tie tickets to new errors**

For each new error from Step 2, call `zendesk-get-ticket` with `subject.contains` set to a short fragment of its message and the after window's dates. Confirm likely matches with `zendesk-get-ticket-comment`.

**Step 5: Report**

* The release: app-version, release-date, errors introduced, unhandled sessions.
* Ticket volume before vs after, with the change as a number and a percentage.
* A table of new errors: error-id, error-class, message (trimmed), events, users, and the ticket-ids linked to it.
* A verdict: did this release measurably increase support load, and which error drove it. If volume rose but no ticket ties to a new error, say the increase is unexplained by Bugsnag.

**Rules & Guidelines:**

* `bugsnag-get-release`, `bugsnag-get-event` and `bugsnag-get-error` are on the bugsnag server. `zendesk-get-ticket` and `zendesk-get-ticket-comment` are on the zendesk server.
* This prompt is read-only. Do NOT call any add, update, assign, fix, ignore, discard or open tool on either server.
* Zendesk tickets are not tagged with app versions, so the link is by timing and wording only. Say so in the verdict.

**Validation:**

* If the after window is still in the future, compare only the days that have passed and scale the before window to the same length.
* If either window has fewer than 5 tickets, report the counts but do not draw a percentage conclusion.
* Pass dates as YYYY-MM-DD.