Find the slow steps holding up your Ghost Inspector suite

**Objective:** Find the Ghost Inspector tests running longer than `{threshold-ms}` milliseconds (default 60000) over the last `{lookback-days}` days (default 14), and say which steps account for the time.

**Step 1: Collect the slow runs**

Call `ghost-inspector-get-test-result` with `execution-time-ms.min` set to `{threshold-ms}` and `date-created.from` set to the start of the window. Keep `test-name`, `suite-name`, `execution-time-ms`, `browser`, `region` and `id` for each.

**Step 2: Separate the consistently slow from the occasionally slow**

Call `ghost-inspector-get-test-result` again with only the date filter, so you have every run. For each test that appeared in step 1, compare its median duration against its worst. A test whose every run is slow has a structural problem; one whose median is fine and worst is bad is contended or waiting on something external.

**Step 3: Find the expensive steps**

For the five slowest tests, take the slowest result `id` and call `ghost-inspector-get-test-step` with that `test-result-id`. Use `date-executed` across consecutive steps in `sequence` order to work out which steps took the longest. Note the `command` and `target` of the worst ones. Long gaps on a wait, a navigation or an assert are the usual cause.

**Step 4: Report**

A table of: test name, suite, median duration, worst duration, browser, region, consistently slow or occasionally slow. Then for the top five, the two slowest steps with their command and target, and a recommendation.

**Rules and guidelines:**

* Read only. Do NOT call `ghost-inspector-execute-test`, `ghost-inspector-execute-suite`, `ghost-inspector-update-test` or `ghost-inspector-update-suite`. This report recommends changes, it does not make them.
* Durations come from `execution-time-ms` on the result and from `date-executed` differences between steps. Do not estimate a step duration any other way.

**Validation:**

* If no run exceeds `{threshold-ms}`, report the slowest run you did find so the user can pick a lower threshold, and stop.
* If a run's steps carry no usable `date-executed` values, say the per step timing is unavailable for it and report only the total.