docs(specs): align the S32 virtual metrics with the code

What

The S32 ### Metrics table now names the labels that the Step 17 code emits:

• All six oci_virtual_* rows label by oci_virtual_operation, not operation.
• resolutions_total labels by resolution_outcome, not outcome.
• A new paragraph names the two label-free S16 token-cache families: gitlab_artifact_registry_oci_remote_token_cache_entries (Gauge) and gitlab_artifact_registry_oci_remote_token_cache_store_refusals_total (Counter).
• A new ## Resolutions bullet records why the labels have scoped names.
• Two ### Wide events sentences name the positions fields an entry omits: outcome when the position reached no verdict, and kind on a skipped_soft_deleted entry or on a position whose observed kind is neither hosted nor remote.
• The positions_consulted row says the metric counts list width: every live position the resolution walked, the excluded and health-gated ones included. The winner's depth is winner_position on the wide event.
• The fourth seam change's ## Dependencies clause and the ### Wide events winner-path paragraph say the slice builds the winner-path positions records. It uses seam wrappers, a second virtual.EligibleUpstreams pass, and the per-resolution health memo. The Collect half stays a foundation change.

The wide event's operation field does not change. It is an event field, not a metric label.

Why

The metrics cardinality audit pins each label's value set by name across the whole service. The bare operation and outcome labels already pin other vocabularies. The Step 17 code therefore emits oci_virtual_operation and resolution_outcome, and a /validate-step run flagged the spec-vs-code mismatch as a blocker. The plan books this amendment in ## Dependencies.

The positions_consulted row used to say the metric shows a winner that sits deep in the list. The histogram has no repository label, so it cannot show that. The Step 17 code counts list width, as the Maven family on !3014 (merged) does.

Merge order

Merge this MR before the S32 Step 17 MR, or together with it. A scraped label cannot change after it ships, so Step 17 must not ship labels that the spec contradicts.

Notes

• The plan scopes the rename to "all three families", but the spec table has six rows. This MR renames all six, so every row names one label. The plan correction goes to the S32 batch docs(plans) MR, !2941 (merged).
• The S30 and S31 rows for the same family keep the old rationale. Their spec authors own the change.
• Open item: collection_requests_total keeps the bare outcome label. Its values (success, absent, unsupported, failed, malformed) cannot join the pinned outcome set. No code emits the collection families yet. The spec author picks a scoped name before a collection route lands.
• No docs/user/ or e2e scenario impact: the change covers operator metrics in a spec.

Related to #291 (closed)

🤖 Generated with Claude Code