Revert to conditional final_entities constraint for facets

Benchmarking on a production-like database shows that always applying
the final_entities subquery (even without filters) causes a 2.6x
regression on the no-filter path (5.2s -> 13.5s) due to ~530k
memoized index lookups against final_entities. The FK cascade from
search -> final_entities already guarantees search rows only exist
for entities with a final_entities row, so the constraint is only
needed when filters route through final_entities.

Signed-off-by: Fredrik Adelöw <freben@spotify.com>
Made-with: Cursor

plugins/catalog-backend/src/service/DefaultEntitiesCatalog.ts

@@ -694,10 +694,12 @@ export class DefaultEntitiesCatalog implements EntitiesCatalog {
       // final_entities, so that the EXISTS-based filters correlate
       // against one-row-per-entity rather than the much larger search
       // table. This keeps the facets aggregation fast even with many
-      // filter clauses or permission conditions.
-      const entityIdSubquery = this.database('final_entities').select(
-        'final_entities.entity_id',
-      );
+      // filter clauses or permission conditions. The whereNotNull guard
+      // ensures that not-yet-stitched (or future tombstoned) entities
+      // are excluded from results.
+      const entityIdSubquery = this.database('final_entities')
+        .select('final_entities.entity_id')
+        .whereNotNull('final_entities.final_entity');
 
       applyEntityFilterToQuery({
         filter: request.filter,