fix(nip45): return COUNT results for filters with generic tag queries

[Anshumancanrock]

Description

countByFilters projected events.event_id twice for any filter carrying a generic tag query
(#e, #p, #g, #h): once on the builder it creates, and again in a tag branch copied from
findByFilters(). The outer count(distinct event_id) then referenced a derived table with two
columns of the same name, which Postgres rejects with 42702 column reference "event_id" is ambiguous. A COUNT mixing a tag filter with a non-tag one failed differently, leaving the UNION
branches with unequal column counts.

This PR removes the second projection. The event_tags join fan-out is
already collapsed by the outer countDistinct. Fixing the arity mismatch falls out of the same
change, since every branch now projects one column.

Add two regression tests

Related Issue

Closes #774

Motivation and Context

nip45.enabled defaults to true and 45 is advertised in supportedNips, so a stock relay
claims COUNT support while failing the two queries COUNT is mostly used for: {"kinds":[7],"#e": [...]} for reactions on an event, and {"kinds":[3],"#p":[...]} for follower counts. Both were
answered with ["CLOSED", <id>, "error: unable to count events"].

The existing countByFilters tests stub .from(), so no SQL reaches a database and substring
assertions pass on the broken query.

[changeset-bot]

🦋 Changeset detected

Latest commit: 6b47384

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
nostream	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[coveralls]

coverage: 72.408% (-0.009%) from 72.417% — Anshumancanrock:fix/nip45-count-tag-filter into cameri:main