fix(firestore): add explicit _apply to QueryConstraint subclasses

[MichaelVerdon]

Description

closes #8923

Related issues

Release Summary

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • Yes
• My change supports the following platforms;
  • Android
  • iOS
  • Other (macOS, web)
• My change includes tests;
  • e2e tests added or updated in packages/\*\*/e2e
  • jest tests added or updated in packages/\*\*/__tests__
• I have updated TypeScript types that are affected by my change.
• This is a breaking change;
  • Yes
  • No

Test Plan

---

Think react-native-firebase is great? Please consider supporting the project with any of the below:

• 👉 Star this repo on GitHub ⭐️
• 👉 Follow React Native Firebase and Invertase on Twitter

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
react-native-firebase	Error		Mar 13, 2026 3:12pm

[mikehardy]

🤔 I may be missing something, but if this (and StartEnd/EndAt/Limit/FieldFilter also) all extend QueryConstraintBase, and it extends QueryConstraint which declares:

  abstract _apply<AppModelType = DocumentData, DbModelType extends DocumentData = DocumentData>(
    query: Query<AppModelType, DbModelType>,
  ): Query<AppModelType, DbModelType>;

...but these implementations are really just duplicating the signature and all calling return super._apply(query) which will chain up to an empty definition....why not make the definition in QueryConstraint concrete (even if empty, just document it's a no-op ?) and then get rid of 5 duplications of the signature with empty methods

Or is there some actual affect happening when you return a call to super._apply even if the inheritance chain seems to lead to an abstract definition?

[mikehardy]

looks clean + minimal to me at this point, I like it

Mr @russellwheatley ?