Docs: Move baseline pipeline selection to the CI/CD testing index

What does this MR do?

Moves the "Baseline pipeline selection" section from doc/ci/testing/metrics_reports.md to doc/ci/testing/_index.md, and links to it from the Code Quality, metrics, and unit test reports pages.

I added the section in !226947 (merged), and lyspin rewrote it in review. Its page is Premium and Ultimate, but the logic is in MergeRequest#comparison_base_pipeline, outside ee/, and the Free Code Quality and unit test reports use it. The testing index is Free.

The first commit moves the section and changes only its heading level. The second commit:

• Names the reports that use this method. Browser and load performance testing use MergeRequest#base_pipeline, which checks the merge-base commit only.
• Says the first SHA comes from merged results pipelines. I wrote merge request pipelines in the original MR, but only the merged results path sets target_sha.
• Says a running pipeline can be the baseline, because MergeRequest#target_branch_pipelines_for does not filter by status.
• Keeps the two metrics facts on the metrics page.

No page in doc/ links to the old anchor. The French and Korean translations have their own copy of the heading.

Related issues

Closes #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.

AI-Generated Content Disclosure: Claude Code wrote this change and this description. Claude Code also checked each claim against the source at commit c740d663 (app/models/merge_request.rb, ee/app/models/ee/merge_request.rb, app/models/ci/pipeline.rb, app/models/concerns/ci/has_status.rb, the merge request pipeline creation services, and the report comparison services), searched gitlab-org with the search API for links to the old anchor, and ran the project's Vale and markdownlint-cli2 configurations on the four changed pages with no blocking findings. The first commit alone has one Vale sentence-length suggestion in the moved text, which the second commit removes. Claude Code then ran each baseline selection behavior the second commit describes on a self-managed GitLab 19.4.1 instance on a test VM, and the instance behaved as described. I read and approved the final text.