build(deps): upgrade openapi-generator to 7.23.0

[jorgeparavicini]

Summary

Upgrades the pinned OpenAPI client generator 7.9.0 → 7.23.0 (latest). Toolchain-only — the generated client is intentionally not regenerated in this PR (see "Deferred" below), so src/ is unchanged and CI (pyright) is unaffected.

Why

On 7.9.0, when the backend's newer Microsoft.OpenApi serializer emits a nullable $ref as {nullable: true, oneOf: [$ref], type: object}, the generator produces an extra wrapper class per field, churning the client and changing its public types. 7.23.0 collapses it to the direct type, making a backend Microsoft.OpenApi 2.x-serializer bump a no-op for the SDK.

Verified: regenerating at 7.23.0 from a 2.10.0-serialized spec vs a 2.0.0-serialized spec produces a byte-identical client (0 files differ). This is what unblocks the backend Directory.Packages.props bump safely.

Two fixes required for 7.23.0 to emit a valid client

File	Fix	Without it
openapi/templates/api.mustache	Blank line after the {{>partial_api}} include	post-7.9 openapi-generator changed standalone-partial whitespace handling; the _response_types_map } collided into } response_data = … → ~60 api files fail to compile
src/.openapi-generator-ignore	Protect rapidata/__init__.py	the generator overwrites the hand-maintained package root (re-exports + __version__) with an empty file

I verified end-to-end that 7.23.0 + these fixes produces a client that py_compiles cleanly and passes pyright src/rapidata/rapidata_client.

Deliberately deferred: regenerating the client

A benchmark/leaderboard filtering refactor is mid-rollout on the backend (structured filter operators + logic, dropped plural leaderboardIds/participantIds list filters — prod is currently ahead of main). Regenerating the client now would entangle that in-flight API change with this toolchain bump and require guessing not-yet-stable filter semantics. Once the generator is on 7.23.0, the automated update-openapi-client workflow regenerates cleanly (and nullable-safe) once that refactor settles.

Test plan

• py_compile on a full 7.23.0 regen (with the template fix): passes
• pyright src/rapidata/rapidata_client on a full 7.23.0 regen (with hand-layer adaptations): 0 errors
• 7.23.0 nullable-representation no-op: 0-file diff between 2.10.0- and 2.0.0-serialized regens
• committed src/ unchanged → existing pyright CI passes

🔗 Session: https://session-44f0d44a.poseidon.rapidata.internal/

[claude]

Review

This is a well-scoped, well-tested toolchain bump. A few notes:

Strengths

• Correctly scoped as toolchain-only: deferring the actual client regen to avoid entangling this with the in-flight backend leaderboard/filter refactor is the right call.
• The two template/ignore fixes are backed by concrete verification (py_compile, pyright, byte-identical regen diff) rather than just theory — good rigor for a change that's hard to verify from the diff alone.
• .openapi-generator-ignore fix for rapidata/__init__.py is a real bug catch: since generate-schema.sh runs -o ./src (the whole src/ tree, not just src/rapidata/api_client/), the generator's __init__package.mustache output would otherwise clobber the hand-maintained __version__/re-export file on any local regen.

Minor suggestions (non-blocking)

1. In api.mustache, consider a one-line comment above the added blank lines (e.g. {# blank line prevents partial's closing brace merging with following statement on generator >=7.x #} — obviously not literal Mustache comment syntax that survives into output, so maybe just a comment in the surrounding prose/PR rather than the template) explaining why the blank line is required. Per this repo's convention of only commenting on non-obvious WHY, a bare blank line added three times looks like a stray formatting change to a future editor who might "clean it up" and reintroduce the bug.
2. The jump 7.9.0 → 7.23.0 skips ~14 minor versions. Worth double-checking the generator's own CHANGELOG for any other whitespace/behavior changes affecting templates you didn't touch (e.g. model.mustache's {{>model_enum}}/{{>model_oneof}}/{{>model_anyof}} includes, which have similar partial-then-code patterns) — sounds like your full regen + pyright pass already exercises these, so this is really just "make sure that regen run covered model-heavy schemas," not a blocking concern.
3. Since this raises the floor for the next auto-generated PR (the update-openapi-client workflow), it might be worth a short note in that workflow or its PR template reminding reviewers that the client will look different this time (wrapper classes collapsing) so it's not mistaken for an unexpected/unreviewed API change.

No bugs, security issues, or missing tests found — the change is toolchain config plus generator templates, and the existing pyright CI gate is unaffected since no generated src/ code changes here. Nice work isolating this from the backend refactor.