--require-indexes (datastore-mode) falsely requires a composite index for an equality-only multi-property query

### [REQUIRED] Environment info
firebase-tools: 15.22.2
Platform: Windows 11

The Firestore emulator, run in datastore-mode with --require-indexes, rejects a query that has only equality filters on two different properties (no inequality, no sort order) as requiring a composite index. Per Google's own documentation, such queries are covered by built-in single-property indexes and should not need one.

### [REQUIRED] Test case
gcloud emulators firestore start --database-mode=datastore-mode --require-indexes --index-file=index.yaml

### [REQUIRED] Steps to reproduce
Run a query equivalent to:
Person.query().filter(Person.google_plus_id == "x").filter(Person.user == True).get()
(REST equivalent: runQuery with a compositeFilter/AND of two EQUAL propertyFilters, no order.)

### [REQUIRED] Expected behavior
Query succeeds using built-in indexes, per "Indexes | Datastore": "Firestore in Datastore mode provides built-in ... indexes for [queries] using only ancestor and equality filters."

### [REQUIRED] Actual behavior
400 FAILED_PRECONDITION: The query requires a composite index that is not defined in your indexes file.

### Impact
Makes --require-indexes unusable at scale — it produces this false positive on every equality-only multi-filter query in the codebase, of which there can be hundreds, making it impossible to distinguish real missing
indexes from noise without manually reasoning through each one.

Start by reproducing the query with the Firestore emulator in datastore-mode using --require-indexes and index.yaml, then compare the REST runQuery compositeFilter/AND case with the equality-only behavior described. Done means equality-only multi-property queries succeed without a composite index while queries that genuinely need one still report the missing index.

Written by the indexing model from the issue text.