Extend recommendation storage/scheduler identity to include purchase-critical Details (tenancy/platform/scope/az_config) #408

Summary

#334 fixed the concrete, reproducible bug: priceRecommendationsFromStore could silently resolve a repriced purchase request (term/payment changed) to a stored recommendation row with a different EC2 tenancy/platform/scope or RDS AZ configuration than the one originally selected, without refusing. That fix (PR #406) is scoped to a boundary check inside internal/api/purchase_pricing.go and does not change how recommendations are collected, stored, or keyed.

#334's own text flagged a broader, unresolved concern that this follow-up tracks:

Define a purchase-complete stable identity shared by collection/storage and repricing... Inspect scheduler ID generation, recommendation storage uniqueness, internal/api/purchase_pricing.go, and provider offering filters together before deciding migration scope.

Residual gap

The store's unique index (migration 000043) and recIdentityKey still key stored recommendations by provider/account/service/region/resource_type/engine/term/payment, WITHOUT EC2 tenancy/platform/scope or RDS AZ config. This means:

• Two recommendations that differ only in tenancy (or AZ config) but share every other field still cannot coexist in storage for the SAME term/payment -- one silently overwrites the other on ingest, which could paper over real availability differences Cost Explorer is reporting.
• Scheduler-generated IDs (RecommendationRecord.ID) also omit these fields, so an ID alone doesn't fully identify the purchase configuration either.
• PR fix(purchase): preserve purchase-detail identity during repricing #406's fix only guards the repricing boundary (comparing the request's original row against the newly resolved row at purchase time); it does not make storage itself purchase-complete.

Proposed follow-up

Analyze and (if warranted) migrate:

1. Extend the stored-recommendation unique key (or add a discriminator column) to include the purchase-critical Details fields identified in fix(purchase): preserve purchase-detail identity during stored recommendation repricing #334 (EC2 tenancy/platform/scope, RDS az_config).
2. Extend scheduler ID generation (RecommendationRecord.ID) to encode the same discriminators, so an ID alone identifies a purchase-complete configuration.
3. Re-verify provider offering filters (providers/aws/services/ec2/client.go etc.) against the extended identity.
4. Add a DB migration + backfill plan for existing rows.

This is a storage/scheduler-level change (new migration, ID format change, backward-compat handling for in-flight purchase_executions rows referencing the old ID format) and warrants its own design pass rather than folding into #334's PR.

References

• fix(purchase): preserve purchase-detail identity during stored recommendation repricing #334 (closed by fix(purchase): preserve purchase-detail identity during repricing #406, this issue's parent)
• PR fix(purchase): preserve purchase-detail identity during repricing #406: repricing-boundary fix