Subscription event loop fans out to wrong-collection events, causing wasted planner work #4896

Split out from #4814 / #4827. Independent of the panic that #4827 fixed.

internal/db/subscriptions.go filters incoming event.Update values only by docID and CID (line 71). There is no filter by collection. As a result, a subscription on collection Book receives Author events, spins up a transaction, builds a planner, fetches a block from the blockstore that belongs to the wrong collection, and only fails inside VersionedFetcher.merge() when the foreign schema rejects the field (ErrFieldNotExist).

Pre-#4827, the resulting close-propagation failure leaked a Badger iterator and crashed the process. Post-#4827 the panic is gone, but the loop still:

• creates a transaction per wrong-collection event
• runs the full planner before discovering the mismatch
• masks the original assumption that RunSelection is the correctness gate — that assumption stopped holding once ToSubscriptionSelect started injecting the event CID, because MultiVersioned does not return an empty result on schema mismatch, it errors

Proposal

Extend the subscriptionSelector interface in internal/db/subscriptions.go:24 with:

CheckCollectionFilter(collectionID string) bool

Implement it on the relevant request.Select types (mirror of CheckDocIDFilter / CheckCIDFilter in client/request/select.go:143-156). Add the guard alongside the existing docID/CID guards at internal/db/subscriptions.go:71. The subscription's target collection should be resolved once at subscribe-time to its root CollectionID and compared against evt.CollectionID.

Refs

• Subscription panics #4814
• fix: Subscription handler iterator leak on join collections #4827
• Original analysis comment by @edjroz