Reject filters implicitly rather that failing a whole request

Flotilla (and NDK) batch requests, which results in valid filters being rejected along with invalid ones. An example: ``` ["REQ","REQ-05681808",{"kinds":[11],"since":1734045039},{"kinds":[1111],"#K":["11"],"since":1734045039},{"kinds":[9],"#h":["5689390638509997"],"since":1734045039}] ``` This results in flaky loading of valid chat messages. It doesn't seem to follow that nip 29 support is incompatible with support of regular nostr events. Relay level authentication and policy is the correct tool for protecting a relay from spam, not feature support, which should be orthogonal (this isn't a commentary on whether nip 29 relays should accept other relays, but that should be up to the instance, not the implementation). If a relay only accepts h-tagged events, returning no events for the first two filters is to be expected. Also, in the case that there are events with h tags that match the first two filters, it's reasonable to return only events that the user has access to based on the relay's prerogative to authorize users. This PR might have many problems with it. I didn't fully understand the logic in NormalEventQuery, but I think my version is clearer (if maybe not quite as performant).