badger, lmdb: match tag values exactly, and check every tag of a filter

[sunmoonron]

This is the bug behind fiatjaf/khatru#52 (the "silent rejection of certain replaceable events"), plus a smaller lmdb gap found while writing the test.

badger. For plain string tag values, and for the d part of a-style values, the tag index key is the value itself with nothing after it, so a prefix iteration for d=a also walks the keys of a-b, abc and so on. The planner then dropped the indexed tag from the post-fetch extraFilter (CopyMapWithoutKey), trusting the index to be exact. So with a-b stored first and newer, publishing an addressable event with d=a was silently not stored: the replace query for d=a returned the a-b event, IsOlder said the new one was older, and shouldStore went false with no error. Plain tag queries had the same false positives. Fix: the indexed tag stays in extraFilter.Tags, so filterMatchesTags checks the fetched event for the exact value. No index format change, no migration.

lmdb. Its keys are already exact for these cases, so it did not have the d=a bug. But when a filter has authors or kinds and two tags the planner has no index preference for (the default branch of ChooseNarrowestTag), prepareQueries returned only one extra tag and the other was never enforced. It now returns the whole TagMap, and the query and both count paths check every tag against the fetched event (tagsMatch).

test. tagPrefixTest runs on every backend from test/db_test.go: d=a next to d=a-b through RelayWrapper.Publish, a tags pointing at those addresses, plain t tags, a two-condition filter, and a two-unknown-tags filter. Without the change it fails on badger at the d=a query and on lmdb at the two-unknown-tags query; with it, TestSliceStore, TestBadger and TestLMDB pass.

Cost: one tag scan per fetched candidate on tag queries, which were already decoding the event.

A length-prefixed or terminated badger index key would remove the false positives at the iterator level instead; that needs a migration, so it is left out of this PR, happy to follow up if you prefer that shape.

🤖 Generated with Claude Code