Optimize MeshModel Registry Summary Queries via Data-Layer Aggregation

[Amr-Shams]

Currently, the MeshModel summary UI (components and relationships counts) is populated by fetching every single entity from the database into memory. In server/internal/graphql/resolver/meshmodel.go, we call GetEntities(), which retrieves thousands of definitions just to perform a GROUP BY and COUNT(DISTINCT ...) operation in memory.

As the MeshModel registry grows, this approach leads to:

1. High Memory Usage
2. UI Latency: Subscriptions for registry updates are slowed down by the $O(N)$ processing time.
3. redundant bandwidth consumed

possible changes

Move the aggregation logic from the GraphQL resolver into the Registry Manager (Meshkit). Instead of fetching full entities, the data layer should perform the grouping and counting.

concerns

right now the existing entity.Filter interface would break or we end up creating brittle.

possible change

Capability Interface (Type Assertion): Introduce a SummaryProvider interface. If a filter (like ComponentFilter) implements it, the Registry Manager uses the optimized path.

Output

Reduce the memory footprint and response time of the /meshmodel/summary endpoint/subscription to near-constant time, regardless of the number of registered entities.

[welcome]

Thanks for opening this issue. A contributor will be by to give feedback soon. In the meantime, please review the Contributors' Welcome Guide, engage in the discussion forum, and be sure to join the community Slack.

[Amr-Shams]

is this solution works out, i can start immediately to do it