fix(shim): resolve real org version instead of hardcoded 9.2.0.0 fallback

[TomProkop]

Problem

CrmServiceClient (our Microsoft.Xrm.Tooling.Connector.CrmServiceClient-compatible shim over Microsoft.PowerPlatform.Dataverse.Client.ServiceClient) hardcoded ConnectedOrgVersion to 9.2.0.0 whenever the base SDK returned its own stub default of 9.0.0.0 — which happens under the token-provider (ExternalTokenManagement) constructor path used by CmtImportRunner, CmtExportRunner, and PackageDeployerRunner.

9.2.0.0 is below CMT's UpsertMultiple batch-mode version gate (9.2.23083.00120), so the Configuration Migration Tool import path silently fell back to slow, one-by-one Create/Update calls through our wrapper — regardless of how modern the real connected org actually is.

Root cause

The underlying SDK's ExternalTokenManagement auth path sets OrganizationVersion = 9.0.0.0 at connect time and skips normal server-version discovery. This was previously worked around (see history of this file) by hardcoding a fallback constant, after earlier attempts using RetrieveVersion/OrganizationDetail were believed to fail silently in that auth mode.

That belief no longer holds for the SDK version we consume (1.2.10) — confirmed live against a real Dataverse online environment (actual org version 9.2.26061.150):

• ConnectedOrgVersion initially reports the SDK's stub default 9.0.0.0.
• ServiceClient.OrganizationDetail (public property, forces a real RefreshInstanceDetails) correctly returns the real version (9.2.26061.150).
• Execute(new RetrieveVersionRequest()) also correctly returns the real version.

Filed upstream for the SDK-level bug: microsoft/PowerPlatform-DataverseServiceClient#538

Fix

Replaced the hardcoded 9.2.0.0 constant in CrmServiceClient.ConnectedOrgVersion with a cascade using only public SDK APIs:

1. Base property (fast path, in case already populated).
2. OrganizationDetail (forces a real refresh).
3. Execute(new RetrieveVersionRequest()) (last resort, strongly-typed request).

If every mechanism still returns the SDK default, the base value is returned honestly instead of substituting a hardcoded constant.

Related

• Complements fix(data/import): pre-populate LookupKeys cache and newId to eliminate redundant CMT server lookups #167 (LookupKeys/newId pre-population) — both fixes reduce CMT import time via different mechanisms: this one restores fast batch upserts (UpsertMultiple), fix(data/import): pre-populate LookupKeys cache and newId to eliminate redundant CMT server lookups #167 removes redundant per-record lookup calls.