Remove useless filtring in events&actions sql

[glyh]

This is confirmed by running this on a online archive db:

 select COUNT(*) from blocks where id = parent_id;
 count 
-------
     0
(1 row)

[glyh]

I think these are auto format.

[45930]

Any reason for this diff?

[glyh]

src/db will be ignored without this

[45930]

I am not confident that this can never be true. I just don't know the Mina spec well enough. What is gained by removing this filter? Is the performance notably better?

[glyh]

No I don't think the perf would be much better. It's just this logic is very confusing here when I'm reading the code

[SanabriaRusso]

Thanks for digging into this and backing it with the COUNT(*) … WHERE id = parent_id = 0 check — the reasoning holds. I confirmed it against the integration fixture too: the genesis block (id=1, height=1) has parent_id = NULL, so the recursive walk already terminates on the NULL parent-join, and pending_chain.id <> pending_chain.parent_id can only ever matter for a self-parented block — of which there are none. So this is a genuine no-op on the returned events/actions rows. (No mina-explorer impact either — it doesn't use events/actions.)

Two small things before merge:

1. Consistency: the identical guard still lives in getZkappsWithPendingEventsQuery in this same file (WHERE pc.id <> pc.parent_id AND pc.chain_status <> 'canonical'). If it's dead code in fullChainCTE, it's dead in both — worth removing it there too (or keeping both) so the file doesn't contradict itself on whether the guard is needed.

2. This guard is effectively an infinite-recursion safety net — a self-parented non-canonical row would recurse forever — and it costs basically nothing to keep. Since we're now relying on the "no block has id = parent_id" invariant, could you drop a one-line SQL comment noting it? That way a future schema/hard-fork change that ever self-references a block surfaces in review instead of as a query hang.

Also, the branch is ~6 weeks behind main and shows BLOCKED — queries.ts hasn't changed on main since your last sync, so it should rebase cleanly and just needs a refresh to re-run CI.