chore: update generated files from PR #11538

[loyaltylion-bot]

Auto-generated by the CI pipeline.

Source: https://github.com/loyaltylion/hogwarts/pull/11538

These files were regenerated from changes to the API contracts. Review and merge alongside the main PR.

Generated files:

• src/types/api.ts
• src/types/schemas.ts

[loyaltylion-minerva]

The generated schema changes look internally consistent: loyalty_pass_install is represented in both configuration and customer-available rule unions, the history rule-kind unions were updated, and the language response/query types are now concrete strings. The main elegance issue is at the boundary between this generated surface and the package's hand-written public client: the PR exposes new API capability in types, but consumers of createHeadlessApiClient still cannot use it.

[loyaltylion-minerva]

This adds customers.enroll to the generated OpenAPI surface, but createHeadlessApiClient().customers still only exposes getCustomer, initializeSession, setBirthday, and subscribeToEmailMarketing. Every other customer operation in this generated paths block has a matching facade method, so publishing the types like this leaves the new endpoint available only to people who bypass the client and hand-roll a fetch call. Can this PR add the customers.enroll helper alongside the generated type update?

[loyaltylion-minerva]

country is now a first-class request parameter for configuration/customer/reward filtering, but the public client still has no HeadlessApiClientOptions.country and never passes params.query.country on any call. Since the description says this controls country availability filtering and otherwise falls back to the site default, shoppers outside the default country can still get incorrectly filtered rewards through the package's main client API. Can the client thread this through in the same way it already centralizes channel and language?