Name the flaky Ghost Inspector tests and what causes them

**Objective:** Identify flaky Ghost Inspector tests over the last `{lookback-days}` days (default 14), counting only tests with at least `{min-runs}` runs (default 5).

A flaky test is one that both passed and failed in the window without its configuration changing. A test that fails every time is broken, not flaky, and belongs in a different report.

**Step 1: Collect both outcomes**

Call `ghost-inspector-get-test-result` with `passing` true and `date-created.from` at the start of the window, then again with `passing` false and the same date filter. Set `max-records` high enough to cover the window in both calls.

**Step 2: Find the mixed ones**

Group by `test-name` across both sets. Keep only tests that have at least one pass and at least one failure and at least `{min-runs}` runs in total. Compute a flakiness rate as failures over runs. Ignore tests at 100 percent failure.

**Step 3: Check whether the configuration explains it**

For each candidate call `ghost-inspector-get-test` with `name.contains` set to that test name and read `auto-retry`, `screenshot-compare-enabled`, `browser` and `region`.

* if failures cluster in one `browser` or `region` it is an environment difference, not flakiness
* `screenshot-compare-enabled` true and `screenshot-compare-passing` false on the failing results means the flakiness is visual diff noise, not a functional failure
* `auto-retry` false on a test that is only intermittently failing is the cheapest available mitigation

**Step 4: Look at where they break**

For the three flakiest, take the most recent failing result `id` and call `ghost-inspector-get-test-step` with that `test-result-id` and `passing` false. A flaky test that always breaks on the same step is a timing problem on that step; one that breaks in different places is an environment problem.

**Step 5: Report**

A table of: test name, suite, runs, failures, flakiness rate, auto retry, screenshot compare, browsers affected. Then for the top three, the step they break on and a recommended mitigation.

**Rules and guidelines:**

* Read only. Do NOT call `ghost-inspector-execute-test`, `ghost-inspector-execute-suite`, `ghost-inspector-update-test` or any create, duplicate or comment tool. Recommend the setting change, do not make it.
* Do not call a test flaky on two runs. Respect the `{min-runs}` floor and say how many candidates you dropped for want of data.

**Validation:**

* If no test has both a pass and a failure in the window, say the suite set is stable over that period and stop.
* If a test name matches more than one test in step 3, say so and treat the configuration check as inconclusive for it.