[Subtask] Define and enforce entity cache eligibility policy

### Describe the subtask

Define a single, explicit eligibility policy for deciding which entities may be stored in the entity cache.

After relation data is removed from `CaffeineEntityCache`, caching safety must not be decided only by whether an entity copies fields from another entity. Some entities contain action-sensitive data, and the authority of schema/table data may differ between managed and connector-backed objects.

This subtask should:

- Introduce one centralized cache eligibility policy shared by all entity cache implementations, including Caffeine and Redis.
- Audit all entity types, including metadata objects, tag, policy, user, group, role, model, model version, function, job, and job template.
- Consider data authority and the effect of stale values, rather than relying only on `EntityType`.
- Distinguish managed/store-authoritative objects from connector-authoritative objects where necessary.
- Make newly added entity types non-cacheable by default until explicitly evaluated.
- Add parameterized tests proving that allowed entities are cached and excluded entities never populate the cache.

Acceptance criteria:

- Caffeine and Redis use the same policy.
- The eligibility matrix and rationale are documented.
- Adding a new entity type cannot silently make it cacheable.
- Tests cover every current entity type.

### Parent issue

#11737

Start by reading parent issue #11737, then locate CaffeineEntityCache and the Redis entity cache implementation. Audit the listed entity types and document an eligibility matrix with its rationale, covering data authority and stale values. Done means both caches use one policy, new types default to excluded, and parameterized tests cover every current type.

Written by the indexing model from the issue text.