feat(azure/savings-plans): wire SP rec collection into scheduler #17

Context

PR LeanerCloud/cloud-commitments-cli#592 added the Azure Savings Plans ServiceClient (provider client + dispatch wiring). The scheduler does not yet call it for rec collection.

Work

Wire ServiceSavingsPlans into the scheduler's Azure rec-collection path, mirroring how AWS Savings Plans recs are collected (via the Cost Explorer centralized path, or -- once the Azure Benefits Recommendations API exits preview -- via the client's GetRecommendations).

Also add the commitmentopts SP probe equivalent for Azure (mirroring probe_savingsplans*.go for AWS).

Depends on

LeanerCloud/cloud-commitments-cli#592 (must land first)

refs LeanerCloud/cloud-commitments-cli#473

Findings from the 2026-09-02 codebase audit

Added by an automated audit of 3c0f8ac94048a2c36fce5ccddee54e6c4849a5cd (tip of origin/main). Each item below was reported by one reviewer and independently confirmed by a second that did not write it. Full report: docs/audits/codebase-audit-2026-09-02.md.

A05-009 (medium)

Worth knowing before anyone starts this: the Azure commitmentopts SP probe already exists as internal/commitmentopts/probe_azure.go (212 lines plus 304 lines of tests), but it is unreachable. ProbeAzure and DefaultAzureProbers have no non-test caller, and the doc comment points at Service.probeAndPersistAzure, which does not exist -- probeAndPersist (service.go:76) only ranges over s.probers, and AzureSPProber cannot join that set because Probe takes an azcore.TokenCredential rather than an aws.Config. The consequence today is that Validate("azure", "savingsplans", ...) always takes the permissive-true branch, so a reader auditing whether Azure SP term/payment combos are validated concludes they are. The wiring work here is therefore either an Azure sibling of probeAndPersist or deleting the file; leaving it as-is is the worst option. (audit finding A05-009)