chore: update generated files from PR #11274

[loyaltylion-bot]

Auto-generated by the CI pipeline.

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

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]

Codegen-only PR. Adds a country?: string query parameter to the 21 operations that already carry the shared channel/language query params (configuration.getConfiguration, the five customers.*, all nine rewards.*, and all six rules.*). The diff is purely additive (42 lines, no deletions) and is mechanically consistent — every block that has language?: unknown gains the same country?: string immediately below it, with identical JSDoc. That matches what you'd expect from a regenerated OpenAPI spec.

A couple of follow-ups worth noting (none of which block this PR — they're not fixable here):

• Wrapper plumbing follow-up. src/client.ts does not currently expose country in any of the wrapped methods. This mirrors the codegen↔wrapper pattern established by PR #23 (codegen for language) → PR #5 (dave/multi-lang-param wrapper exposure). If SDK consumers need to vary country per-request, a follow-up PR will need to surface it on the wrapper (either as a per-call argument or, like language, a client-construction option that becomes an X-LoyaltyLion-Country header — whichever shape the server side actually accepts). Worth pre-empting the question rather than leaving the param dangling at the typed-paths layer.
• JSDoc copy. See line comment — the description text reads as if it was authored for the rewards endpoints and then applied uniformly. Source spec issue (hogwarts #11274), not codegen, so the fix has to land server-side.

Otherwise looks good to merge alongside hogwarts #11274.

[loyaltylion-minerva]

The JSDoc "ISO 3166-1 alpha-2 country code for the customer. Used to filter rewards by country availability." is identical across all 21 endpoints — including ones that aren't reward-related (e.g. customers.setBirthday at line 8964, rules.completeFacebookLike at line 10371, customers.emailMarketingSubscribe at line 9078). "Used to filter rewards by country availability" is the right description for the rewards/configuration endpoints (where reward visibility is country-gated) but reads as a copy-paste on rules.complete* and the customer side-effect endpoints, where there's no reward list in the response to filter.

Two angles worth a sanity-check upstream in hogwarts #11274:

1. Is country actually doing anything on the non-reward endpoints, or is it just being added to the shared "common query params" set without per-endpoint semantics? If the latter, narrowing the JSDoc to only the endpoints where it's load-bearing (or generalising the description so it doesn't claim "filter rewards" everywhere) would be more honest.
2. The type is bare string rather than a length-2 / pattern-constrained schema (compared to language?: unknown, this is at least typed, but ISO 3166-1 alpha-2 is a tight 2-char format). If the server-side spec can express minLength: 2, maxLength: 2, pattern: '^[A-Z]{2}$' (or an explicit enum), the codegen would carry it through and catch a class of bad inputs at compile time.

Both of these are server-spec fixes — leave the codegen output alone here, but probably worth a comment on hogwarts #11274 before that PR merges.