Make undercoverage job fail tier 2 pipelines

What does this MR do?

Changes the if-merge-request-tier-3 rule of .rails:rules:rspec-coverage in .gitlab/ci/rules.gitlab-ci.yml to if-merge-request-tier-2-or-above, so a failed undercoverage check in the rspec:coverage job now fails tier 2 pipelines as well as tier 3. Updates the matching sentence in doc/development/pipelines/_index.md.

Unchanged: tier 1 and untiered merge request pipelines still fall through to the rule that sets UNDERCOVERAGE_FAILURE: "allow", so failures stay allowed there. The skip-undercoverage and run-all-rspec label handling, and the pipeline::expedite and non-EE exclusions, are also unchanged.

Why

!224144 (merged) made undercoverage run earlier in tier 2, but allowed it to fail. The Slack discussion concluded that because failures are allowed, nobody (people or agents) fixes them, so the early run has little value.

Risk is low:

• Tier 2 passing is not required for maintainer approval or merge.
• A tier 3 pipeline still runs the check.

Easily reverted

Reverting this MR, or changing that one rule back to if-merge-request-tier-3, restores the previous behavior.

Related issues

• Original change: !224144 (merged)
• Builds on !265673 (merged), which moved the check into rspec:coverage and added UNDERCOVERAGE_FAILURE.
• Known gap, tracked separately: #637215 (closed)

Checklist

Pre-merge

Consider the effect of the changes in this merge request on the following:

• Different pipeline types: only tier 2 merge request pipelines change; tier 1, untiered, and tier 3 are unchanged.
• Non-canonical projects:
  • gitlab-foss: not affected, the rule already excludes non-EE.
  • security
  • dev
  • personal forks
• Pipeline performance: no new jobs, no change in job count or duration.

If new jobs are added: not applicable, no jobs are added.

Post-merge

• Consider communicating these changes to the broader team following the communication guideline for pipeline changes