Geo - Replicate AlertManagement::MetricImage uploads

What does this MR do and why?

Add Geo SSF (self-service framework) replication and verification for the alert_management_alert_metric_image_uploads partition table, so alert metric image attachments are mirrored from the primary to secondary Geo sites alongside other upload types.

Generated with scripts/geo/generate-blob-replicator and adjusted for AlertManagement::MetricImage specifics:

• Shorten Postgres identifiers (idx_ prefix with amm_upload alias for the table name) to fit the 63-character limit on the state-table indexes and registry indexes (the full table name is 43 characters).
• Factory uses :alert_metric_image (the actual parent factory name in the repo) and destroys CarrierWave's auto-created Upload before creating the controlled :with_file fixture, since AlertManagement::MetricImage always attaches a file in its after(:build) hook.
• Selective-sync spec uses the alert → project hierarchy (alert: create(:alert_management_alert, project:)) since AlertManagement::MetricImage does not accept a project: keyword directly.
• registry_consistency_worker_spec patch fixed to use the correct factory name :geo_alert_management_metric_image_upload (generator emitted :geo_metric_image).

Replication is gated by the ops feature flag geo_alert_management_metric_image_upload_replication (default disabled); flipping it on for general availability is tracked separately under the parent epic.

Changelog: added EE: true

References

• Relates to #589904 (closed)
• Parent epic: gitlab-org#20933 (per-upload-partition Geo replication)

How to set up and validate locally

Validation requires a local Geo setup (primary + secondary), and make sure you run geo migrations with: rails db:migrate:geo. Then:

1. On the primary, enable the feature flag:

   ```ruby Feature.enable(:geo_alert_management_metric_image_upload_replication) ```

2. Create an `AlertManagement::MetricImage` with an attached file (via the incident/alert detail page metric images section, or in the Rails console).

3. On the secondary, watch the registry get populated:

   ```ruby Geo::AlertManagementMetricImageUploadRegistry.last ```

   Confirm it transitions through `pending → started → synced` and that `verification_state` reaches `succeeded`.

4. Confirm the file exists on the secondary's object storage / disk at the same path as the primary.

5. Spot-check the GraphQL API:

   ```graphql { geoNode(name: "") { alertManagementMetricImageUploadRegistries { nodes { id state } } } } ```

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.