Check whether a Bugsnag error already has a work item

**Objective:** Find any Azure DevOps work items that track Bugsnag error {error-id}, searching the work-item project {ado-project} if given (default: all projects).

**Step 1: Read the error (Bugsnag)**

Call `bugsnag-get-error` with `error-id`. If nothing returns, stop. Note `error-class`, `message`, `severity`, `status`, `events`, `first-seen-date`, `last-seen-date` and `error-url`.

**Step 2: Search for work items (Azure DevOps)**

Call `azure-devops-get-work-item` with `title.contains` set to the error id, passing `project` when {ado-project} is given. If nothing returns, repeat with `title.contains` set to the error class, then to a short distinctive fragment of the message. Only keep a hit whose title, description or url clearly mentions the error id, class or message; say which of the three matched.

**Step 3: Report**

The error summary, then each candidate work item (id, type, title, state, assigned-to, priority, url) with its match basis. Finish with one verdict: tracked, possibly tracked, or untracked.

**Rules & Guidelines:**

* Tools prefixed azure-devops are on the Azure DevOps server; tools prefixed bugsnag are on the Bugsnag server. Both must be connected.
* Read-only job. Never call `bugsnag-link-error-issue`, `bugsnag-create-error-issue`, `bugsnag-assign-error`, `bugsnag-fix-error`, `bugsnag-ignore-error`, `bugsnag-discard-error`, `bugsnag-open-error`, `bugsnag-update-error-severity`, `bugsnag-update-project`, `bugsnag-add-project` or `bugsnag-add-project-collaborator`. The Azure DevOps server has no write tools.

**Validation:**

* A title match on the class alone is weak evidence; label it so.
* If the Azure DevOps search returns nothing, say the error appears untracked and do not create anything.