Docs: Correct the cause of a missing Test summary panel

What does this MR do?

When the Test summary panel is missing from a merge request, the troubleshooting topic says the target branch might have no test data, and asks the reader to run a target branch pipeline.

The target branch doesn't decide whether the panel appears. The panel renders only when the merge request has a test reports path (testReportWidget). GitLab sets that path only when the pipeline shown in the merge request (pipeline) has a JUnit report (test_reports_path, MergeRequest#has_test_reports?, Ci::Pipeline#has_test_reports?). With no baseline report, the comparison starts from an empty report (TestReportsComparer), so the panel lists every failed test as new (new_failures). The test result types section on the same page already says that, with no target branch data, the panel shows the failed tests from the source branch.

This MR replaces that cause with three ways a pipeline ends up without a JUnit report, and the steps that resolve them.

How the merge request decides what the panel shows

flowchart TD
    P["Pipeline shown in the merge request"] --> R{"Any job uploaded a JUnit report?<br/>MergeRequest#has_test_reports?"}
    R -- "No" --> X["No Test summary panel"]
    R -- "Yes" --> B{"Baseline pipeline has a JUnit report?"}
    B -- "Yes" --> C["Test summary compares the two reports"]
    B -- "No" --> N["Test summary lists every failed test as new"]

Related issues

Related to #593215 (closed)

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.

An AI coding assistant wrote this change and this description. It checked each code claim against the source at commit e81286bf, ran the project's Vale and markdownlint-cli2 configurations on the changed page with no findings on the changed lines, and ran each behavior described above on an unlicensed self-managed GitLab 19.4.1 instance on a test VM. The merge request title cases were not run on the test VM. They rest on merge_request_title_skips_ci?, the default merge commit message, and the skip a pipeline documentation.