Optimize Registrar Actions Queries

[shrugs]

the registrar actions count query needs to do a bunch of joins and a full table scan, making it much slower than the paginating query. in a recent pr (#1870), we optimized it slightly for some cases by conditionally joining necessary tables, based on the selected filter BUT some additional improvements could be made by materializing some of the registrar actions data to avoid the joins

background on count query slowness: https://namehash.slack.com/archives/C086Z6FNBHN/p1775230819876179

the ideas claude and i came up with are:
0. in count query, only join registry lifecycle if necessary

• requires correctness consideration, since the act of joining excludes entries without a corresponding lifecycle and we may or may not need that behavior

2. materialize counts per subregistry (incl the filter dimensions)
3. denormalize subregistries.node onto registrar_actions to avoid the join into subregistries