Decompose PolarisMetaStoreManager into distinct implementations and divide responsibilities

### Is your feature request related to a problem? Please describe.

Currently, the `PolarisMetaStoreManager` is the central interface to:

* Persistence and retrieval of persisted entities
* Storage and validation of secrets
* Privilege/grant management
* Entity cache validation/eviction/refresh
* Credential vending

#417 did some initial work to break up the interface into multiple interfaces so that components can depend on the specific functionality they require (i.e., persistence only or credential vending only), but the core interface itself still extends all of these interfaces and any metastore implementation must implement all of the methods in every interface. This makes it very difficult to swap out components for specialized tools, such as Vault for secrets management or redis for distributed caches or some policy-based grant manager.

### Describe the solution you'd like

The `PolarisMetaStoreManager` interface should no longer depend on any of the other interfaces and should contain persistence-only method definitions. This allows for persistence implementations to focus only on entity storage and retrieval, while other components can be responsible for implementing secrets management or credential vending. Furthermore, the cache logic should be refactored so that business components, such as the `PolarisServiceImpl` don't need to know anything about the entity cache, but can deal with the persistence interface directly. Caching may be implemented under the hood, but that should be transparent to the business components.

### Describe alternatives you've considered

_No response_

### Additional context

I've started a doc at https://docs.google.com/document/d/1MNCdW-uKVZaR5Ua91FDwxhreBeGjPOoV-CyF0WOWwIg/edit?tab=t.0 that can be used to iterate on a class design so that it's clear how responsibilities are divided. This should prevent multiple people from making conflicting changes while the core components are being refactored.

Start with the linked class-design document and map the responsibilities currently combined in PolarisMetaStoreManager, including persistence, secrets, grants, caching, and credential vending. Then inspect how PolarisServiceImpl and metastore implementations use those responsibilities. Done means an agreed design and a refactoring plan that separates persistence from the other components without conflicting changes.

Written by the indexing model from the issue text.