Vector Entries Resource Can Create N+1 Knowledge Entity Queries

Bug

The Vector Entries table shows related knowledge entities by reading each row's knowledgeSource and then querying knowledgeNodes() from that source.

Because the resource query does not currently eager-load the source and node relationships used by the table display, a page with many vector entries can execute an extra relationship query per row.

Impact

The Vector Entries admin page can become slow as the number of visible rows grows. The issue is mainly a UI performance concern; it should not affect indexing correctness, retrieval correctness, or tenant isolation.

Current Status

Still open. This was found in a follow-up Copilot review after the sequential async indexing work.

This is lower risk than the queue/provider/data-integrity comments, so it is deferred with the other non-blocking RAG cleanup work.

Proposed Solution

Avoid per-row relationship queries in the table display.

Possible approaches:

• Eager-load knowledgeSource.knowledgeNodes in the Vector Entries resource query, if that keeps the table query shape reasonable.
• Add a small source-scoped aggregate query for the visible row set and render names from that preloaded map.
• Limit the displayed entity names consistently with the current UI behavior.
• Add a regression test or query-count-oriented coverage if the app already has a pattern for detecting N+1s in Filament resources.