Spot recurring ServiceNow incidents that need a problem record

**Objective:** Find recurring incident patterns over the last `{lookback-days}` days (default 30), optionally within `{assignment-group}`, that deserve a problem record.

**Step 1: Pull the incidents**

Call `servicenow-get-incident` with opened.from set to today minus `{lookback-days}` days, assignment-group `{assignment-group}` if given, and max-records 500.

**Step 2: Cluster**

Group the incidents by, in this order of strength:

1. same configuration-item
2. same service
3. same category plus two or more shared distinctive words in short-description

A cluster needs at least 3 incidents. Ignore clusters whose only common factor is a generic category such as Inquiry.

**Step 3: Check for an existing problem**

For each cluster call `servicenow-get-problem` with short-description.contains set to the CI name or the shared words. A matching open problem, or one flagged known-error, means the cluster is covered: note its number.

**Step 4: Report**

A table ranked by cluster size and priority: pattern, incident count, highest priority, first and last opened date, example incident numbers (up to 5), existing problem (number or None). Then recommend which uncovered clusters to raise as problems, with a draft short-description for each.

**Rules & Guidelines:**

* Read-only. Do not call `servicenow-add-problem`, `servicenow-add-problem-task`, `servicenow-update-incident` or any other add- or update- tool. The raise-problem-from-incidents prompt creates the record.
* Do not merge clusters that only share a word like "error" or "slow".

**Validation:**

* If there are fewer than 3 incidents in the window, say there is not enough data and stop.
* If the result hit 500 records, say the window was capped and suggest a shorter lookback.