Refresh OpenAPI specifications and regenerate SDK clients

[sierk-techletes]

Summary

Refresh all eight bundled ZeroFriction OpenAPI specifications from the vendor's current Azure API Management export and regenerate the Python SDK clients with OpenAPI Generator 7.13.0.

This updates the generated models and endpoints to the current documentation, including the unit-price tariff subtype exposed by the Configuration API. It also adds a reproducible Docker-based generation command and provenance documentation.

Compatibility

• Preserve the API-version query compatibility behavior across all eight clients.
• Remove the customer lookup and billing DTO workarounds that are now represented by the refreshed schema.
• Keep the country-code compatibility patch because the vendor schema still publishes a closed enum.
• The current exports group operations under DefaultApi; the README and regeneration guide document the resulting change from resource-specific attributes such as contracts_api to default_api.
• Update locked pip and tornado versions to address the advisories reported by the repository's mandatory audit.

Validation

• uv run --frozen pytest -q — 6 passed.
• uv run --frozen pre-commit run --all-files — all hooks passed, including pip-audit.
• Running ./scripts/generate-sdk.sh twice produced identical SDK diffs.
• No live API writes or tariff requests were performed.

Closes #12

[thom-techlete]

Thanks for putting this together. I’m not going to merge this PR in its current form, because we’re changing how SDK regeneration/release updates are handled.

The refreshed specs and generated clients can introduce breaking changes in the generated Python surface (for example renamed API modules/models), so we want to treat a full regeneration as a versioned SDK update rather than merging it directly once the repo itself passes.

The new workflow is documented in #14:

• tag the current SDK as v1;
• create a dedicated regeneration branch (planned as chore/regenerate-sdk-v1.1);
• update the OpenAPI specs and regenerate all clients there with the pinned generator version;
• test the candidate branch against all dependent projects/repos;
• only after downstream compatibility is confirmed, open/merge the SDK PR to main and tag that release as v1.1.

I’ll therefore close this PR without merging it. We can reuse the useful generation/provenance work from here when preparing the new v1.1 regeneration branch.