Bug: Redis control plane keys not deployment-scoped

[alexluong]

Problem

When multiple Outpost deployments share the same Redis instance (using different DEPLOYMENT_ID values), control plane keys collide because they lack a deployment prefix.

Data keys are correctly scoped, but control plane keys are not:

Redis keyspace
├── tm_001:tenant:{ten_abc}:tenant          ✅ scoped to tm_001
├── tm_001:tenant:{ten_abc}:destinations    ✅ scoped to tm_001
├── tm_002:tenant:{ten_xyz}:tenant          ✅ scoped to tm_002
├── tm_002:tenant:{ten_xyz}:destinations    ✅ scoped to tm_002
│
├── outpostrc                               ❌ shared
├── .outpost:migration:lock                 ❌ shared
├── outpost:migration:001_hash_tags         ❌ shared
├── outpost:migration:002_timestamps        ❌ shared
└── outpost:migration:003_entity            ❌ shared

Example

• tm_001 runs outpost migrate redis apply → sets outpost:migration:002_timestamps status to applied
• tm_002 runs outpost migrate redis plan → sees 002 as already applied, skips it

Proposed Solution

Prefix control plane keys with deploymentID: when set, and rename for consistency:

• outpostrc (hash with installation field) → outpost:installation_id
• .outpost:migration:lock → outpost:migration_lock

Redis keyspace
├── tm_001:tenant:{ten_abc}:tenant                  ✅
├── tm_001:tenant:{ten_abc}:destinations            ✅
├── tm_001:outpost:installation_id                  ✅
├── tm_001:outpost:migration_lock                   ✅
├── tm_001:outpost:migration:001_hash_tags          ✅
│
├── tm_002:tenant:{ten_xyz}:tenant                  ✅
├── tm_002:tenant:{ten_xyz}:destinations            ✅
├── tm_002:outpost:installation_id                  ✅
├── tm_002:outpost:migration_lock                   ✅
└── tm_002:outpost:migration:001_hash_tags          ✅