Improve management review parameter compatibility checks against GA baselines

[live1206]

Problem

The management SDK review flow reported multiple parameter compatibility findings on #61970 that were false positives because it compared custom code with the previous repository source shape instead of the released GA assembly configured by ApiCompatVersion.

Examples incorrectly flagged as breaking changes even though they exactly matched GA metadata:

• StaticInputData(..., windowStart, windowEnd) in Azure.ResourceManager.MachineLearning 1.2.4.
• MachineLearningAzureDataLakeGen2Datastore(credentials, filesystem, accountName) in 1.2.4.
• Machine Learning service-principal and certificate credential constructor ordering in 1.2.4.
• InitialAgentPoolConfiguration(count, mode, name, vmSkuName) in Azure.ResourceManager.NetworkCloud 1.3.0.
• AlertRuleData and DiagnosticSettingData factory parameter names/order in Azure.ResourceManager.Monitor 1.3.1.
• Machine Learning compatibility overload parameter names: GA uses skip, not the names from the previous repository source.

The flow did correctly identify two distinct issues:

• Compatibility overloads forwarded skip into the generated kind parameter.
• Monitor GA factory parameters were optional but the custom replacements made them required.

Expected behavior

For compatibility customizations, the review flow should use the package's ApiCompatVersion assembly as the authoritative baseline for public parameter names, ordering, and optionality. Repository history/current main can provide context, but should not override released assembly metadata.

Acceptance criteria

• Resolve the package baseline version from <ApiCompatVersion>.
• Inspect the released baseline assembly metadata before reporting parameter-order/name/optionality breaks.
• Distinguish signature compatibility from forwarding/runtime-semantic bugs.
• Do not claim an API was "previously shipped" unless it exists in a released baseline.
• Include the compared baseline version and exact baseline signature in each finding.
• Add regression coverage for the false-positive and valid-finding examples from Update management emitter to 1.0.0-alpha.20260811.2 (part 3/4) #61970.

Additional false-positive examples from #61971

The optional-parameter scanner reported 22 blocking findings without evaluating the complete overload set or compiling representative GA calls:

• SQL (15): GA calls remain source-compatible through alternate overloads. Examples include SqlDatabaseCollection.GetAll(), job-execution list methods where the new long? overload preserves omitted arguments while the int? overload preserves typed positional calls, DataMaskingPolicyResource.GetDataMaskingRules(), managed-database security-event methods, and SqlServerResource.GetRestorableDroppedDatabaseAsync(...).
• Security Center (2): both SecurityCenterPricingCollection.GetAll() and GetAll(cancellationToken) compile against the updated overload set because the new filter overload preserves the parameterless call.
• App Service (5): the kind-first factory overloads preserve calls to SiteAuthSettingsV2, AppServiceEnvironmentAddressResult, and CsmDeploymentStatus; changing required parameters to optional on the single ResourceNameAvailability and ResourceNameAvailabilityContent overloads does not create overload ambiguity or break existing calls.

The flow should inspect all overloads and compile representative positional and named GA calls before classifying OPTPARAM001 or OPTPARAM002 as blocking. Textual optionality differences alone are insufficient.

- by copilot