Add a workflow that audits the api client against the OpenAPI spec

[jhonabreul]

Description

Adds a GitHub Actions workflow, api-client-sync, that audits the C# API client against the QuantConnect OpenAPI spec and opens pull requests with the fixes.

• Runs monthly on a schedule and on demand through workflow_dispatch, on the self-hosted foundation container like the other workflows.
• Downloads the current spec and hands it to the Claude Code action with a fixed prompt: walk every endpoint, compare it with Api and its models, and fix every difference.
• The prompt covers new endpoints and members, mismatches in request and response shapes, sibling normalization, IApi parity, parameter ordering, and obsoleting instead of removing.
• Downstream repositories that use the client are checked out next to Lean and updated for the changed members in the same run.
• Those repositories come from the API_SYNC_DOWNSTREAM_REPOS repository variable, a json array of up to three repository names within the organization.
• One pull request per repository that changed, on a fixed branch so a rerun updates the open PR instead of opening another.
• Claude's summary becomes each PR description; a changed repository without a summary still gets a PR with a placeholder body.

Related Issue

N/A

Motivation and Context

The client drifts from the documented API over time, as with #9798, and nothing catches it. This makes the comparison a recurring job that produces reviewable PRs.

Requires Documentation Change

No.

How Has This Been Tested?

• The workflow file parses, and the spec download step was run locally with the same command.
• The audit prompt was run locally, scoped to the order and log endpoints: it found the discarded total count, the missing algorithmId, the missing log filters, and the missing backtest log endpoint, and fixed them.
• The full-spec audit prompt was run locally across all 62 endpoints and produced compiling changes with passing offline fixtures.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• Refactor (non-breaking change which improves implementation)
• Performance (non-breaking change which improves performance. Please add associated performance test and results)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Non-functional change (xml comments/documentation/etc)

Checklist:

• My code follows the code style of this project.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes. A workflow definition has no unit tests; it was exercised by running its steps locally.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>