Sync the api client with the OpenAPI spec

[jhonabreul]

Description

Every endpoint of the QuantConnect OpenAPI spec was compared with Api and its models, and every difference fixed. Stacked on #9808, which should merge first.

New endpoint methods:

• UpdateProject and ReadBacktestLog, declared on IApi as well.

Missing members the client never sent or exposed:

• Request: start/end on ListProjects, parameters on CreateBacktest, projectId on ListLiveAlgorithms, algorithmId on ReadLiveInsights, query and deploymentLogs on the log methods.
• Response: Project.MaxFileSize, Backtest.Debugging, BacktestReport.Generating, ReadChartResponse.Status/Progress, OrdersResponseWrapper.Status/Progress, CreateLiveAlgorithmResponse.Live, LiveAlgorithmResults.Description, LiveAlgorithmSummary.Equity/Environment/Description, ListObjectStoreResponse.Page/TotalPages.

Mismatches with the documented request or response:

• ReadBacktestInsights posted to an undocumented path and never reached the endpoint; it now posts to the documented one.
• Card.LastFourDigits was a decimal, dropping leading zeros; now a string.
• ReadBacktestReport treated a report still generating as an empty success; it keeps polling while Generating is set.
• SummaryObjectStore.IsFolder read isFolder and never populated; the API sends folder.
• ReadLiveAlgorithm required a deployId the request does not document and the server ignores; it is gone, and the results converter reads every field optionally and the errors from the errors array.
• IApi defaults for ListBacktests and UpdateBacktest differed from the class, so calls through the interface sent different payloads; aligned.

Left out on purpose: the project collaboration, brokerage authorization and AI tool endpoints; the Project.isPinned, Project.sharingTokenBacktest, LiveAlgorithmSummary.leagues and LiveAlgorithmResults.isPublicStreaming members and the codeSourceId request field of the file methods, which serve the web terminal rather than a user or an LLM; and, until the API serves them, the file patch endpoint and the compile parameters.

Spec discrepancies: reviewers must verify

• account/read documents no request body, but the client sends organizationId to select an organization, and the spec has no organization endpoint at all. Kept.
• Project.parameters is documented as a name to value map; the API returns a list of name and value objects. Client kept.
• ReadBacktestChartRequest marks start and end required; the API treats them as optional and defaults to the full range. Client kept.
• backtests/tags/update and Backtest.ServerStatistics are undocumented but served. Kept, not obsoleted.
• BacktestSummary.SecurityTypes is a string in the client and an integer count in the spec. Kept.
• CreateOptimizationResponse.extremum is documented on the create and list responses, but only optimizations/read sends it; create and list only carry it inside criterion. Client reads it on the read model only.
• Optimization.extremum and targetValue at the top level duplicate criterion, which the client already maps; not added. targetValue comes back null even when set on create.
• CreateCompileResponse.parameters is always empty on create, before the build runs, and compile/read does not carry it at all. Left out of the client until the API serves it.
• files/patch answers success without applying the patch. Left out of the client until the API applies it.
• files/update is documented to answer with the updated files; the API answers with a plain rest response. Client kept.
• object/list folder flag: the spec's folder was confirmed against the real API; the old isFolder was wrong.

Related Issue

#9798

Motivation and Context

The client had drifted from the documented API in ways that silently dropped data or never reached an endpoint.

Requires Documentation Change

Yes: the six items in the discrepancies section above are candidate spec fixes.

How Has This Been Tested?

All in the credentialed fixtures that the API tests workflow runs, for manual runs with api credentials:

• ProjectTests: 10 tests, one per project, file and backtest change, asserting the request sent or the documented member returned.
• ReadLiveInsightsWorksAsExpected now deploys twice: the algorithmId reads one deployment, and omitting it reads every deployment of the project together.
• LiveTradingTests: the live create summary, reading the latest live deployment, and the project filter on the live list.
• ObjectStoreTests: one test for the new listing members.
• LiveAlgorithmResultsJsonConverterTests: 4 unit tests for the converter, 8 in the suite passing.

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.
• All new and existing tests passed.
• My branch follows the naming convention bug-<issue#>-<description> or feature-<issue#>-<description>