feat(mempool): allow subscribing to unconfirmed_txs via WebSocket - #6035

closes #1770

Adds a MempoolTx event, fired when a tx is admitted into the mempool (passes
CheckTx for the first time), mirroring how the existing Tx event is fired
on block commit. Clients can subscribe with tm.event='MempoolTx' instead of
polling /unconfirmed_txs.

Use case

Answering the maintainer's question on the issue thread: MEV/backrunning
tooling and network diagnostics both want to observe txs the moment they enter
the mempool, not just once committed - polling /unconfirmed_txs on an
interval misses the timing precision either use case needs.

Scope: CListMempool only

AppMempool (mempool.type = "app") is a separate, newer implementation that
doesn't touch the EventBus at all today - wiring it there is left as a
follow-up rather than folded into this change. Documented explicitly in
docs/core/subscription.md: a node running mempool.type = "app" or "nop"
currently receives nothing on a MempoolTx subscription, with no error. Happy
to track that as a separate issue if useful.

Things worth knowing before merging

Publish is synchronous under CheckTx's read lock. PublishEventMempoolTx
follows the exact same pattern as the existing PublishEventTx (unbounded
context, error logged not propagated) - but the underlying pubsub Server
dispatches on an unbuffered channel by default
(EventBusBufferCapacity defaults to 0), and CheckTx holds
updateMtx.RLock() for its entire body with the local ABCI client. So if the
pubsub loop is momentarily busy (e.g. draining a big block's Tx events into
an unbuffered subscriber like the indexer), a MempoolTx publish - which now
fires per admitted tx, not per block - queues behind it, and mempool-admission
latency inherits that delay. No deadlock: the indexer never takes mempool
locks, and it only subscribes to Tx/NewBlockEvents queries by default, so
it never receives MempoolTx itself. Operators who care can raise
event_bus_buffer_capacity. Flagging rather than restructuring the publish
path, since it matches the existing Tx-event pattern exactly.

No zero-subscriber fast path. Every admitted tx now pays a Tx.Hash()
computation, a couple of map allocations, and a pubsub dispatch, even with zero
MempoolTx subscribers - across every gossiped tx network-wide, not just
locally submitted ones. Small relative to the ABCI round-trip per CheckTx,
but nonzero. Happy to add an opt-in mempool.publish_events config flag as a
follow-up if that overhead matters to node operators.

Queries without a tm.event clause now also match MempoolTx. Since
PublishEventMempoolTx indexes the CheckTx response's app events and the tx
hash into the same composite-key space Tx events use, a subscription like
transfer.recipient='X' (no tm.event filter) will now also receive
mempool-admission events if the app emits that event in CheckTx, not just on
commit. Built-in flows are unaffected (EventQueryTxFor always includes
tm.event='Tx', and cosmjs's tx-search/subscribe paths do the same), but a
hand-rolled subscriber without a tm.event clause changes behavior. Keeping
the shared key space since hash-based filtering is a real part of this
feature's value, but calling it out explicitly rather than leaving it for a
reviewer to discover.

Testing

New test in mempool/clist_mempool_test.go: real CListMempool + real
EventBus + an in-memory kvstore app, subscribes via EventQueryMempoolTx,
asserts the subscriber receives EventDataMempoolTx with the right tx bytes
and CheckTx code.

go build ./... clean. gofmt -l clean on all changed files. go vet ./mempool/... ./types/... ./node/... ./rpc/... clean (one pre-existing,
unrelated finding on unmodified main, confirmed not touched by this diff).
go test ./mempool/..., ./types/..., ./node/..., ./rpc/core/... all
pass, plus a targeted rerun of the existing TestTxEventsSent to confirm no
regression on the adjacent, pre-existing Tx-event subscription flow.