chore: api type sync

[kyle-ssg]

Thanks for submitting a PR! Please check the boxes below:

• I have added information to docs/ if required so people know about the feature!
• I have filled in the "Changes" section below?
• I have filled in the "How did you test this code" section below?
• I have used a Conventional Commit title for this Pull Request

Changes

Output of the Claude api sync, this validates the current RTK types against Flagsmith's API and builds a cache.

How did you test this code?

• Validated updated types

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
flagsmith-frontend-preview	Ready	Preview	Comment	Oct 21, 2025 9:21am
flagsmith-frontend-staging	Ready	Preview	Comment	Oct 21, 2025 9:21am

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
docs	Ignored	Preview		Oct 21, 2025 9:21am

💡 Enable Vercel Agent with $100 free credit for automated AI reviews

[github-actions]

Docker builds report

Image	Build Status	Security report
ghcr.io/flagsmith/flagsmith-api-test:pr-6181	Finished ✅	Skipped
ghcr.io/flagsmith/flagsmith-e2e:pr-6181	Finished ✅	Skipped
ghcr.io/flagsmith/flagsmith-api:pr-6181	Finished ✅	Results ✅
ghcr.io/flagsmith/flagsmith:pr-6181	Finished ✅	Results ✅
ghcr.io/flagsmith/flagsmith-private-cloud:pr-6181	Finished ✅	Results ✅
ghcr.io/flagsmith/flagsmith-frontend:pr-6181	Finished ✅	Results ✅

[khvn26]

I understand and appreciate how this improves the developer experience for our FE engineers and contributors.

My only issue with this, albeit a significant one, is that it undermines Flagsmith's "API-first" approach by causing the FE to completely ignore the OpenAPI schema. Currently, our schema is already unusable for code generation (#6183), and I'm afraid bypassing it for its main consumer, the Flagsmith UI, will cause it to deteriorate further, which goes against our long-term goals.

While I appreciate the relatively quick gain introduced by this PR, I believe that investing in #6183 and relying on the currently available industry-standard codegen tools would benefit a wider audience of contributors and product users in the long run.