## Problem/motivation The pre-beta5 review in #3586404+s found selection cache-metadata gaps and unbounded entity-memory growth during catalog scans. None are exploitable built-in holes on their own, but they can cache an injected unpublished item for the wrong user, or hold tens to hundreds of MB until request shutdown. #3586420+s is the rc1 index prefilter for Relevant. This issue does not replace that work. These two listing routes are admin routes. Core Dynamic Page Cache ships `DenyAdminRoutes`, so they already answer `UNCACHEABLE` and do not show a stale page after save. The tags are still the metadata the forms should declare. ### 1. Consumer admin listings omit the config tags they render `AiContextConsumersForm` and `AiContextConsumerTypeOverviewForm` opt into Dynamic Page Cache with permanent max-age but omit `config:ai_context.consumers`, `config:ai_context.consumer_type_settings.*`, and `ai_context_item_list` (the global-count column). Beta4's agent listing declared no `#cache`, so it stayed fresh. ### 2. Selection results omit consumer and scope-settings config tags `AiContextSelector` and `AiContextSelectionFactory` attach `ai_context.settings` and item/list tags, but not `config:ai_context.consumers` or the applicable `config:ai_context.scope_settings.*` tags. A consumer or scope-settings save can leave a cached selection result in place. ### 3. Injected-item access checks discard cacheability `AiContextSelectionItemsSelectedEvent` validates injected items with a boolean `$item->access('view')`. That drops the access-result `user` context, cache tags, and max-age. A subscriber can inject an unpublished owner-visible item. The selection result then lacks the metadata needed to vary or invalidate when another user sees the cached output. ### 4. Relevant/Broad scans retain loaded entities in the static entity cache `AiContextSelector::loadPublishedItemsChunk()` never evicts after each 200-item chunk. The sibling `AiContextSubscriptionBudgetCalculator` already calls `memoryCache->deleteMultiple()` for the same problem. Even after the #3586420+s prefilter lands, Broad leftover fill and any remaining chunked scan still hydrate full entities and can hold them until request shutdown. ## Proposed resolution - Add the missing config and list tags to both consumer admin listings (or set `max-age: 0` on those forms). - Add `config:ai_context.consumers` and the applicable `config:ai_context.scope_settings.*` tags to selection results. Additive; not an API freeze change. - In `assertItems()`, use `access('view', ..., TRUE)`, add the access result as a cacheable dependency, and keep the fail-closed deny. - After each published-item chunk is matched, evict those entities from the entity memory cache the same way the budget calculator does. Do not change selection results. - Document Minimal as the recommended selection mode for large catalogs (site default can stay Relevant). `docs/features/context_selection.md` and `docs/developers/debugging.md` already say to use Minimal to prefilter; make that an explicit large-catalog recommendation next to the #3586420+s prefilter notes. ## Tests - Kernel: consumers listing includes `config:ai_context.consumers` and `ai_context_item_list`; type overview includes each `config:ai_context.consumer_type_settings.{id}`. - Kernel: selection results include consumer and used scope-settings config tags. - Kernel: injecting an unpublished owner-visible item bubbles that access result's cacheability onto the selection result. - Kernel: after a multi-chunk Broad scan, loaded candidate IDs from the first page are not still present in the entity memory cache. - Existing selection-ladder kernel tests still pass. ## Out of scope - Cloning `getCacheableMetadata()` (tracked on #3586444+s) - Constructor `assert()` replacement (tracked on #3586444+s) - Relevant index prefilter (already #3586420+s) - Persistent `VariationCache` of `select()` results (post-1.0; invalidation across path/entity/user is the design work) - Renderer token-count algorithm - Usage-tracker save batching - Subcontext child bounds and Broad warning suppression - Per-item `isEnabledAndAvailable()` config lookups in the match loop ## Related issues - #3586404+s - #3586300+s - #3586420+s - #3586444+s ## AI usage - [x] AI assisted issue