Context

The provider-agnostic provision validation feature (#9019) lets extensions register validation checks with a RuleId. Today the rule-ID namespace is global: core enforces uniqueness on check_type + rule_id across all installed extensions (internal/grpcserver/validation_service.go onRegisterRequest), and the RuleId/DiagnosticId strings are the only thing that maps a finding back to its owning extension.

Core already knows the owning extension.Id at registration and dispatch time (validationCheckEntry.Extension), but it is not surfaced in:

• the preflight report (pkg/output/ux/preflight_report.go), or
• telemetry (PreflightExtensionRulesKey / PreflightDiagnosticsKey in pkg/infra/provisioning/provision_validation.go).

As a result, each extension must hand-roll an extension prefix in its rule ID to keep findings mappable. For example, azure.ai.agents now uses azure.ai.agents.resource_group_location_mismatch (see PR #9007), and the demo extension uses bare IDs like demo_provision_warning. This is inconsistent and easy to get wrong.

Problem

When we add rule suppressions, rule sets, or per-extension enable/disable in the future, customers need a reliable way to map a rule to the extension that owns it. Relying on a hand-rolled string prefix convention is fragile and not enforced.

Proposed options

1. Auto-namespace rule IDs — core prepends the owning extension.Id to the registered RuleId (e.g. <extension.Id>/<rule_id> or <extension.Id>.<rule_id>), so extensions register short, local IDs and the effective/global ID is derived consistently. Update the global-uniqueness check accordingly.
2. Dedicated extension-id field — carry extension.Id as a structured field alongside each finding in the preflight report and telemetry (PreflightExtensionRulesKey/PreflightDiagnosticsKey), so rules are mappable without string parsing.
3. Both (1) and (2).

Option 2 (or 3) is likely the most robust: a structured field avoids parsing and preserves the raw rule ID.

Acceptance criteria

• A finding surfaced by an extension check can be unambiguously mapped to its owning extension id, without relying on a hand-rolled string convention.
• Telemetry records the owning extension id for each invoked rule / diagnostic.
• Existing extensions (demo, azure.ai.agents) continue to work; document the recommended rule-ID convention.

References

• Feature: feat(provision): provider-agnostic provision validation checks #9019 (provider-agnostic provision validation checks)
• Consumer / motivating review: Add resource group location mismatch provision validation check (azure.ai.agents) #9007 (azure.ai.agents resource-group location check) — reviewer @tg-msft raised the global-rule-ID mapping concern.