Split the listMessages monolith into a registry-driven dispatcher

[jrnxf]

This was generated by AI during triage.

From architecture review candidate #3 (recommendation: Worth exploring). Captured for triage.

Problem

listMessagesServerFn in the messages module is a ~330-line function with 7 type branches of 60–80 lines each. Query construction is trapped inside conditionals, so it can only be tested end-to-end through a mocked DB — the interface is not the test surface.

Proposed solution

With the registry in place, the per-type branches collapse into one registry-driven query builder. Any type that genuinely needs bespoke logic gets its own listXxxMessages() behind the same dispatcher interface.

Benefits

• Each query path becomes independently testable.
• The dispatcher shrinks to a lookup; reviewers see new-entity wiring at a glance.

Relationships

• Likely overlaps with merged slice EntityRegistry slice 3 — rewire messages through the registry (all content types) #9 (rewire messages through the registry). Triage must first check whether EntityRegistry slice 3 — rewire messages through the registry (all content types) #9 already collapsed these branches — if so, this is an already-implemented wontfix; if EntityRegistry slice 3 — rewire messages through the registry (all content types) #9 only swapped table lookup but left the 330-line structure, this is the follow-up to actually split it.
• Depends on EntityRegistry — one module owns the engagement entity map #6 (EntityRegistry).