[Phase 5] Rename MergeRequestsClosingIssues model to MergeRequestIssue

What does this MR do and why?

Phase 4 of persisting MR ↔️ Work Item relationships (see #601174). This MR completes the model class rename half of #456869 (closed): the awkwardly-named MergeRequestsClosingIssues model becomes MergeRequestIssue — the Rails-conventional name for the eventual merge_request_issues table. Phases 1–3 already renamed the associations (merge_request_issues / merge_request_closing_issues) in anticipation of this.

No behavior change. This is a pure rename/refactor.

Why the table is not renamed here

The DB table rename (merge_requests_closing_issues → merge_request_issues) is deliberately out of scope and tracked as a separate effort (Phase 5). GitLab renames tables online via a two-release, view-based process (rename_table_safely → finalize_table_rename, TABLES_TO_BE_RENAMED), and several factors make it its own dedicated change:

• It cannot share a release with the link_type column add (Phases 1–3, 19.1) — table modifications are not allowed during the rename window.
• The table has a project_id backfill trigger (trigger_9f3745f8fe32); the rename docs advise caution with triggered tables.
• The table is replicated to ClickHouse via the siphon framework (siphon_merge_requests_closing_issues), which keys off the source table name.

Until then, the model points at the existing table:

class MergeRequestIssue < ApplicationRecord
  self.table_name = 'merge_requests_closing_issues'

What changed

• Model: app/models/merge_requests_closing_issues.rb → app/models/merge_request_issue.rb, class MergeRequestsClosingIssues → class MergeRequestIssue, plus the self.table_name pin.
• Policy: MergeRequestsClosingIssuesPolicy → MergeRequestIssuePolicy (lookup is by class name, so it must track the model).
• Factory: :merge_requests_closing_issues → :merge_request_issue (file → spec/factories/merge_request_issues.rb); all ~27 spec consumers updated.
• GraphQL GlobalID type: MergeRequestsClosingIssuesID → MergeRequestIssueID, with regenerated doc/api/graphql/reference/_index.md and both public/-/graphql/introspection_result*.json. The affected types were introduced in Phase 3 (behind the unreleased mr_work_item_relations flag), so there are no existing clients to break.
• Database dictionary: db/docs/merge_requests_closing_issues.yml classes: entry updated to MergeRequestIssue (the file stays table-keyed).
• .rubocop_todo: pre-existing grandfathered offenses repointed from the old model/policy paths to the new ones (no underlying code changes).

Migration class names (AddLinkTypeToMergeRequestsClosingIssues, the CH siphon migrations) keep the old name — they are tied to their filenames/versions, not the model.

How to validate locally

bundle exec rspec \
  spec/models/merge_request_issue_spec.rb \
  spec/policies/merge_request_issue_policy_spec.rb \
  spec/graphql/types/merge_requests/work_item_relation_type_spec.rb \
  spec/services/merge_requests/work_item_relations/destroy_service_spec.rb

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist.