pdp: use the reorg-check hash index for the pending message queue panel

[TippyFlitsUK]

Priority

Not urgent. GUI-only cost; nothing functional is affected.

The problem

The pending eth messages query in web/api/webrpc/message_queue.go joins message_sends_eth on the computed key lower(trim(both from mse.signed_hash)). No plain-column index can serve that, so every render of the message queue panel hash-joins against a full scan of message_sends_eth:

->  Hash Right Join
      Hash Cond: (lower(TRIM(BOTH FROM mse.signed_hash)) = mwe.signed_tx_hash)
      ->  Seq Scan on message_sends_eth mse  (rows=5687145)

On my two calibnet SPs (5.5M and 5.7M send rows) that is 8.5 s per render, logged over 1,300 times in one node's recent log window. Nodes with smaller send tables or an empty pending queue stay under the 5 s slow-log threshold, which is why it only surfaces on high-volume nodes.

The matching index already exists: 20260527-pdpv0-reorg-chk-indexes.sql ships idx_message_sends_eth_signed_hash_norm on exactly this expression, partial on send_success = true AND signed_hash IS NOT NULL. The panel query cannot use it because a bare LEFT JOIN must also consider rows outside that predicate.

The change

Rewrite the join as a LATERAL probe with send_success = TRUE, which makes the existing partial index legal and turns the full scan into one point probe per pending message:

->  Index Scan using idx_message_sends_eth_signed_hash_norm on message_sends_eth mse
      Index Cond: (lower(TRIM(BOTH FROM signed_hash)) = mwe.signed_tx_hash)
Execution Time: 64.693 ms

8,459 ms to 64.7 ms on the same node and data. No schema change. Sends with send_success = false are excluded from the join; a wait row is only inserted after successful submission, so no pending wait matches such a send.

Verification

Running on both calibnet SPs. Zero slow-SQL warnings since restart; the panel returns identical results.

[LexLuthr]

Do you know why we were doing the LEFT join in the first place? It just doesn't make sense to do a JOIN here.

[TippyFlitsUK]

It came in with the panel itself in #1351 - the join is only there to show send_reason and send_time next to each pending hash. message_waits_eth only holds the hash and status, so the two tables have to be combined somewhere to render the panel. Happy to restructure it however you'd prefer - or drop the reason/time columns if that's the better call.