[Task]: Centralize Redis governance keyspace conventions

[rian-be]

Summary

Add dedicated Redis keyspace component for governed mutation requests so key naming, index key composition, and Redis storage conventions are centralized in one place.

Goal

Make Redis key generation explicit, reusable, and consistent across persistence and query paths instead of letting key conventions spread through the provider implementation.

Scope

What should be implemented?

• Add the ModularityKit.Mutator.Governance.Redis.Keys area for Redis keyspace concerns
• Define central keyspace type for request document keys
• Define keys for request revision storage
• Define keys for request id indexes
• Define keys for state based, status based, and pending request indexes
• Keep key naming conventions configurable through provider options
• Reuse the keyspace component across Redis persistence and query services
• Document the Redis keyspace conventions in provider docs and ADRs where needed

Acceptance Criteria

• Redis key naming is centralized instead of duplicated across the provider
• Persistence and query code use the same keyspace conventions
• Request documents, revisions, and secondary indexes have explicit key definitions
• Key prefix configuration applies consistently across all Redis keys
• The keyspace design remains internal to the Redis provider boundary and does not leak into governance abstractions

Notes

Redis backed governance needs stable and predictable key naming for both write and read paths. A dedicated keyspace component reduces drift, keeps provider internals coherent, and makes later changes to index strategy safer.

This should align with the Redis provider architecture and storage strategy ADRs.

Related ADRs:

• ADR-029: Governance Redis Provider Package
• ADR-030: Governance Redis Request Storage and Query Strategy
• ADR-032: Governance Redis Concurrency and Index Maintenance Model