GitHubApiResponseCache has no cross-instance invalidation

[jpgough-ms]

GitHubApiResponseCache (was CalmCacheService, #3064) is a per-JVM, in-memory Caffeine cache with no cross-instance invalidation. Safe for its only consumer GitHub API response caching in GitHubVersionService (#3066) — because:

• GitHub backend is read-only through calm-hub: every mutation on GitHubArchitectureStore and siblings throws GitHubWriteNotSupportedException.
• GitHub backend already tolerates ~60s per-instance eventual consistency by design: GitHubSyncScheduler runs an unguarded @Scheduled(every=60s) per instance, no leader election, each instance holding its own clone and InMemoryRegistryService snapshot.

Unsafe for Mongo/Nitrite data: that backend supports full CRUD (ArchitectureResource, PatternResource, FlowResource, ControlResource, NamespaceResource — all @POST/@PUT/@DELETE). A write on instance A never invalidates instance B's cached read.

Precedent: ADR 0006 rejected a CountsService-style TTL cache for a Mongo read path ("does nothing for a cold cache and adds a staleness window"). Not a blanket rule; doesn't address multi-instance. CountsService itself still runs this pattern today (5s TTL, ConcurrentHashMap) — separately tolerated, out of scope here.

Fix (delivered in #3064 + #3066)

• Moved org.finos.calm.cache.CalmCacheService → org.finos.calm.store.github.util.GitHubApiResponseCache.
• Replaced the generic get/put/getList/evict API with getVersions/putVersions, getContentAtSha/putContentAtSha. TTLs and key formats are private constants, not caller-supplied — reuse for Mongo data now requires editing the class, not just calling it differently.
• Removed evict/evictByPrefix (zero production callers).
• Renamed calm.cache.max-size → calm.github.cache.max-size.

Out of scope

• A distributed/shared cache.
• Changes to CountsService.