Regenerate all connector clients from the type-identity generator fix

[daviburg]

Description

Regenerates every connector client from the type-identity generator fix in AzureUX-BPM PR 16618864, bringing the checked-in clients back into sync with the generator.

That BPM PR has merged to master as commit 729bc0651c, so this output now matches what the generator on master produces.

Changes

• 75 clients regenerated. Of those, 4 change because of the type-identity fix - AzureAD, Office365, Pipedrive, Planner. AzureIoTCentral, the fifth affected client, already landed separately in Regenerate AzureIoTCentral from the type-identity generator fix #225.
• The other 71 carry accumulated output from generator fixes that merged after those files were last regenerated, not new behaviour from this change.
• CHANGELOG.md records the breaking model renames.

Registries deliberately excluded. ConnectorNames.cs and ManagedConnectors.cs are not touched. Regenerating them from the catalogue snapshot used here would have dropped 25 existing constants (including docusign and jira), because those registries are built from the connectors actually processed and the snapshot was short 24 of 1619 catalogue entries. Syncing them needs a complete catalogue fetch and should be its own PR.

Public surface audit

The full method-set diff against the checked-in clients is 13 added, 3 removed. None of that comes from the type-identity fix: regenerating each affected client from the pre-fix generator and diffing against the post-fix output gives 0 added and 0 removed for every one of AzureMonitorLogs, Box, Dropbox, DynamicsAX, ExcelOnlineBusiness, Ftp, SharePointOnline, Typeform. The entire delta is drift between long-stale checked-in files and the current generator plus catalogue.

Removed (3). All are x-ms-visibility: internal in the connector swagger and are not referenced by any discovery annotation, so the generator correctly stops emitting them as public methods:

Client	Methods no longer emitted
DynamicsAX	GetExportableTableAsync, GetExportableTablesAsync
SharePointOnline	GetListImageFieldsAsync

Added (13).

• 8 public operations that were simply missing - ListFolderAsync and ListRootFolderAsync on Box, Dropbox, Ftp, SharePointOnline. Swagger visibility is important / advanced, so these belong on the public surface.
• 4 internal operations retained as discovery targets, because a definition pins them through x-ms-dynamic-schema / x-ms-dynamic-values: AzureMonitorLogs.QuerySchemaV2Async, AzureMonitorLogs.ListTimeRangeTypesAsync, Typeform.GetSchemaAsync, ExcelOnlineBusiness.GetSingleScriptV2Async.
• 1 unverified - DocuSign.StaticResponseForEmbeddedSigningSchemaV2Async. docusign is one of the 24 catalogue entries missing from the snapshot, so it was fetched live and its swagger was never cached. The name matches the discovery-target pattern above, but I could not confirm it from source.

One pre-existing generator issue surfaced by this regeneration. Typeform.GetSchemaAsync binds to the wrong schema revision. Typeform's swagger is internally consistent - each trigger generation is paired with its own schema operation:

Trigger	Payload definition	Pinned schema operation
TrigNewResponse (deprecated)	Item	GetSchema (/v1/form/{form_id})
NewResponseWebhook (V0)	Item-New	GetSchema_V2 (/forms/{form_id})
NewResponseWebhook_V2 (V2)	WebhookPayload	GetSchema_V3 (/v3/forms/{form_id})

The generator drops NewResponseWebhook in favour of NewResponseWebhook_V2 (logged, with a capability-gap check), so the retained trigger is the V2 one - whose payload pins GetSchema_V3. But the emitted GetSchemaAsync calls /forms/{form_id}, which is GetSchema_V2, the partner of the dropped trigger. Nothing is emitted for GetSchema_V3.

Two contributing factors, both pre-existing:

• CollectDynamicSchemaDiscoveryOperationIds scans every swagger definition unconditionally, so all three revisions get whitelisted as discovery targets whether or not any retained operation reaches them.
• ResolveVersionCollisions groups by version-stripped base name and keeps the highest revision with a logged drop. It would have preferred GetSchema_V3 and logged dropping GetSchema_V2. No such warning appears in the generation log, so GetSchema_V3 was removed before the collision resolver saw it. I have not identified which stage removes it.

This is not caused by the type-identity fix - regenerating Typeform from the pre-fix generator produces the same two methods. It does not break the build, and the affected operation is an internal discovery helper rather than a customer-facing action. Flagging it here for follow-up rather than expanding this PR's scope.

Testing

• Unit tests added/updated

• All existing tests pass (dotnet test)

• Manual testing (describe below if applicable)

• dotnet build succeeds across all 97 clients.

• 935 tests pass, 0 failures.

• 23 tests added across 8 files covering the newly emitted and renamed surface: Box, Dropbox, Ftp, SharePointOnline, AzureMonitorLogs, DocuSign, ExcelOnlineBusiness, Typeform.

• Generation evidence from the source branch: full catalogue produces 1517 files with 0 connectors failing, and the emit-time shape guard is active as a hard failure.

• DocuSign and Jira were regenerated too. They were initially absent from the catalogue snapshot, so they were fetched live rather than left stale.

The generator behaviour behind this output is covered by the generator's own suite (549 tests) in the paired BPM PR.

Checklist

• Code follows the project's coding conventions
• No modifications to files under src/**/Generated/ (see CONTRIBUTING.md)
• Documentation updated (if behavior changed)
• CHANGELOG.md updated (if user-facing change)
• release_notes.md updated (if shipping a new version, clear previous version notes)
• Version updated in eng/build/Version.props (if shipping a new version)

The Generated/ checkbox is intentionally left unchecked: this is a generator-driven regeneration, which is the sanctioned way those files change, matching #224 and #225. No file here was hand-edited.

Authored with Dobby agent.

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of lines (20,000). Try reducing the number of changed lines and requesting a review from Copilot again.

[daviburg]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 1 pipeline(s).

[Copilot]

Copilot wasn't able to review this pull request because it exceeds the maximum number of lines (20,000). Try reducing the number of changed lines and requesting a review from Copilot again.