feat: intent-based cache API (createCache.io, .minimal, .production, .secure)

[27Bslash6]

Context

The Python SDK has intent-based decorator variants that abstract away backend/reliability/encryption configuration into a single declarative intent:

@cache.minimal(ttl=300)     # speed-first, no circuit breaker
@cache.production(ttl=600)  # reliability-first, circuit breaker + timeout
@cache.secure(master_key=k) # zero-knowledge encryption
@cache.io(ttl=3600)         # SaaS backend, full features

The TypeScript SDK currently requires users to manually compose backends, reliability, and encryption:

const cache = createCache({
  backend: cachekitioWithLocking({ apiKey }),
  reliability: { circuitBreaker: { ... } },
  encryption: { masterKey },
});

Proposal

Add intent-based factory functions to the createCache namespace:

const cache = createCache.io({ apiKey, ttl: 3600 });
const cache = createCache.minimal({ url: 'redis://...', ttl: 300 });
const cache = createCache.production({ url: 'redis://...', ttl: 600 });
const cache = createCache.secure({ url: 'redis://...', masterKey: '...' });

Each intent pre-configures the full stack (backend selection, reliability settings, serializer, encryption) so users declare what they want, not how to wire it.

Implementation Notes

• Intent layer sits ABOVE the backend layer (uses the composition architecture from the CachekitIO parity work)
• .io() creates CachekitIO with locking + TTL + metrics + session tracking
• .minimal() creates Redis backend with no circuit breaker, no encryption
• .production() creates Redis backend with circuit breaker + adaptive timeout
• .secure() creates Redis backend with AES-256-GCM encryption
• Python reference: cachekit-py/src/cachekit/decorators/intent.py and cachekit-py/src/cachekit/config/decorator.py

Depends On

CachekitIO backend full parity (currently in progress).