1.3 Record internal and audit events for catalog_items

What does this MR do and why?

Records what each GET .../catalog_items request served and refused.

• One internal event, resolve_ai_catalog_flow_sub_items. Its label is served, refused (GitLab refused at least one sub-agent), or skipped (a setting turned the sub-agents off). It also has the served and refused counts and the skip reason.
• One audit event, ai_catalog_flow_sub_agent_refused, for each agent the session could not use. It names the agent by its item ID and version only. A skipped resolution writes no audit event, because GitLab already audits changes to the feature flag and the Duo beta setting.

The recording is in Ai::Catalog::Tracking::WorkflowItemsResolutionRecorder, next to the other AI Catalog tracking code, so the resolver stays small.

DWS calls this endpoint on each turn, so the events are written on each turn until ai-assist!7898 merges. After that, DWS calls it once for each session.

Related to #628315 (closed).

How to set up and validate locally

Use the setup and call helper from !261254 (merged).

1. Gitlab::CurrentSettings.update!(instance_level_ai_beta_features_enabled: false), then call "$WORKFLOW_ID". The response has no sub-agents, and Admin > Monitoring > Audit events has no new row. Revert. On GitLab.com, the setting is experiment_features_enabled on the top-level group.
2. agent_version.update_column(:release_date, nil), then call "$WORKFLOW_ID". One ai_catalog_flow_sub_agent_refused row with the agent's item_id, version, and code: unknown_version. Revert.
3. The internal event has no UI. workflow_items_resolution_recorder_spec.rb asserts its exact properties for the served, skipped, and refused cases.

MR acceptance checklist

• I have evaluated the MR acceptance checklist for this MR.