docs: add UI screenshots for recent flaky-tests and merge-queue changes

flaky-tests/dashboard.mdx

@@ -90,6 +90,13 @@ You can _click_ on any of the test cases listed on the Flaky Tests dashboard to
 
 In addition to the tabbed content, the test details page shows the test’s current status (Healthy, Flaky, or Broken), ticket status, and codeowner information.
 
+The **Monitors** tab opens on a monitor history swimlane: one row per monitor, each showing a 30-day timeline of the classifications it produced. Bars are colored by status (or by the label's color for label monitors). By default the swimlane shows only monitors with recent activity; the **Show inactive and disabled monitors** toggle reveals rows for disabled monitors and monitors with no events in the last 30 days.
+
+<Frame caption="The monitor history swimlane on the Monitors tab: each monitor's classifications over the past 30 days, one row per monitor.">
+<img className="block dark:hidden" src="/assets/flaky-tests/monitor-history-swimlane-light.png" alt="A swimlane timeline on the Monitors tab with rows for Test Status, a failure-rate monitor, a pass-on-retry monitor, and a second failure-rate monitor, spanning May 27 to June 26." />
+<img className="hidden dark:block" src="/assets/flaky-tests/monitor-history-swimlane-dark.png" alt="A swimlane timeline on the Monitors tab with rows for Test Status, a failure-rate monitor, a pass-on-retry monitor, and a second failure-rate monitor, spanning May 27 to June 26." />
+</Frame>
+
 ## Code owners
 
 If you have a codeowners file configured in your repos, you will see who owns each flaky test in the test details view. We support code owners for [GitHub](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) and [GitLab](https://docs.gitlab.com/ee/user/project/codeowners/) repos.
@@ -143,6 +150,11 @@ You can flip through the stack traces of similar failures across different test
 
 The Test History tab gives you full visibility into every individual run of a test. Use it to investigate patterns across branches, find specific failing runs, and drill into error details.
 
+<Frame>
+<img className="block dark:hidden" src="/assets/flaky-tests/test-history-tab-light.png" alt="The Test History tab with a result and quarantine filter bar, a daily runs chart, and a paginated table of individual test runs." />
+<img className="hidden dark:block" src="/assets/flaky-tests/test-history-tab-dark.png" alt="The Test History tab with a result and quarantine filter bar, a daily runs chart, and a paginated table of individual test runs." />
+</Frame>
+
 ### Daily runs chart
 
 A stacked bar chart at the top of the tab shows daily test run counts. The legend identifies four categories:

flaky-tests/detection/pass-on-retry-monitor.mdx

@@ -51,6 +51,11 @@ A common pattern is to run one monitor scoped to stable branches (like `main`) w
 
 To add a monitor, go to **Settings** in the Trunk web app, open the repository, navigate to the **Monitors** tab, and click **Add monitor**. Each monitor you create appears as a separate row in the monitors table and can be individually enabled, disabled, or deleted.
 
+<Frame caption="The Monitors tab lists each monitor as its own row, grouped into Health classification and Lifecycle & performance. Add Monitor creates an additional monitor in the same repository.">
+<img className="block dark:hidden" src="/assets/flaky-tests/detection/repo-monitors-tab-light.png" alt="The repository Monitors tab showing a pass-on-retry monitor, two failure-rate monitors, and lifecycle monitors, each as a separate row with an Add Monitor control." />
+<img className="hidden dark:block" src="/assets/flaky-tests/detection/repo-monitors-tab-dark.png" alt="The repository Monitors tab showing a pass-on-retry monitor, two failure-rate monitors, and lifecycle monitors, each as a separate row with an Add Monitor control." />
+</Frame>
+
 ### What Recovery Days Controls
 
 A shorter recovery period (e.g., 1 to 3 days) returns tests to healthy quickly, which is useful if you fix flaky tests promptly and want fast feedback. A longer recovery period (e.g., 10 to 15 days) is more conservative. It keeps tests flagged longer to account for flaky behavior that only surfaces occasionally.

merge-queue/administration/advanced-settings.mdx

@@ -7,6 +7,11 @@ All of the following settings are specific to individual Merge Queues and can be
 
 Settings are organized into sections accessible from the sidebar: **General** (state, mode, merge method, timeouts, concurrency), **GitHub** (required statuses, comments, labels), **Slack** (notifications), and **Batching**. Each section has its own URL, so you can link teammates directly to a specific group of settings.
 
+<Frame caption="Merge Queue settings are split into sidebar sections: General, GitHub, Slack, and Batching, plus Sudo when enabled for your org. Each section has its own URL.">
+<img className="block dark:hidden" src="/assets/merge-queue/administration/settings-sidebar-sections-light.png" alt="The Merge Queue settings page with a sidebar listing General, GitHub, Slack, Batching, and Sudo, showing the General section's controls." />
+<img className="hidden dark:block" src="/assets/merge-queue/administration/settings-sidebar-sections-dark.png" alt="The Merge Queue settings page with a sidebar listing General, GitHub, Slack, Batching, and Sudo, showing the General section's controls." />
+</Frame>
+
 <Info>
 Organization admin access is required to change any of these settings. Non-admins see all controls in a disabled state. Hovering over a disabled button shows a tooltip explaining the restriction.
 </Info>
@@ -212,6 +217,11 @@ All three work regardless of which testing mode you chose (Draft PR or Push-Trig
 3. Use the CI job selector to choose which status checks must pass. The selector shows GitHub status check and check run names observed on recent pull requests in your repository. If a check name does not appear in the list (for example, a new workflow not yet seen on a recent PR), type it in directly and press Enter to add it.
 4. Selected statuses override the GitHub branch protection defaults for the merge queue
 
+<Frame caption="The GitHub section of Merge Queue settings. Click Configure under Required Statuses to pick the CI checks the queue waits on.">
+<img className="block dark:hidden" src="/assets/merge-queue/administration/github-settings-section-light.png" alt="The GitHub section of Merge Queue settings showing GitHub Comments, Commands, Label Commands, State Labels, GitHub Statuses, Browser Extension, and Required Statuses with a Configure control." />
+<img className="hidden dark:block" src="/assets/merge-queue/administration/github-settings-section-dark.png" alt="The GitHub section of Merge Queue settings showing GitHub Comments, Commands, Label Commands, State Labels, GitHub Statuses, Browser Extension, and Required Statuses with a Configure control." />
+</Frame>
+
 <Info>
 When required statuses are configured in Trunk, only those statuses are required for the merge queue. When not configured, Trunk falls back to your GitHub branch protection required checks.
 </Info>