Seed four code review tables that had no fixture

What does this MR do and why?

Adds db/fixtures/development/41_code_review_workflow.rb, which seeds four tables that previously had neither a factory nor a fixture:

Table	Rows seeded	Note
approval_merge_request_rules_users	2	EE, seeded from ee/db/fixtures/development/41_code_review_approval_rules.rb. The parent approval rule is itself unseeded, so the fixture creates one if needed.
merge_request_user_mentions	2	One row with a note, one without.
commit_user_mentions	2	One per note, on real head commits.
excluded_merge_requests	1	No model exists, so raw SQL guarded with NOT EXISTS.

Because nothing seeded them, all four were empty in the upgrade-stop PG dump used by db:migrate:multi-version-upgrade, so migrations touching them never ran against real rows. Part of gitlab-org&23121, which tracks tables lacking fixture data.

Why insert_all rather than models

Deliberate. The aim is the row shapes a long-lived instance actually contains, including nulls in columns that are nullable today but might not be after a future migration. Model validations would reject exactly those shapes.

Sharding keys are still populated explicitly, using the values each table's BEFORE INSERT sync trigger would derive itself (insert_all bypasses validations and callbacks, not triggers). Writing the derived value keeps the rows readable and matches what the application produces.

Testing

Ran on a local GDK at the review revision (6a37bb9d). First run on an empty database seeds 2 / 2 / 1 / 2 rows across the four tables, plus 2 commit notes and 1 approval rule as dependencies; a second run leaves every count identical, confirming idempotency. Per-row checks: namespace_id equals the project's project_namespace_id, each commit_id equals its note's SHA, and project_id on the rules_users rows equals the parent rule's. With RAILS_ENV=test on an empty database, both fixtures print skip messages and exit cleanly. run-dev-fixtures-ee is green on this revision in CI.

Note for database review

The insert_all calls each write one or two rows in a development seeder, so there are no query plans to attach.