fix(aws/redshift): verify reserved-node tagging contract used by purchase idempotency #107

Summary

Verify and correct the Redshift reserved-node tag contract used for purchase idempotency. The current code depends on tag operations on a constructed reserved-node ARN, but AWS's documented taggable resource list does not include reserved nodes. Adding IAM actions alone does not establish that this resource/API combination is supported.

Current behavior

At 81f2fc3ac44ce47221682fa1c50dec26e4f24eed, providers/aws/services/redshift/client.go:

• scanNodesForToken constructs arn:aws:redshift:<region>:<account>:reservednode:<id> for active/payment-pending nodes and calls nodeHasIdempotencyTag (lines270-286).
• nodeHasIdempotencyTag calls DescribeTags; any lookup error propagates and causes a tokened purchase to be refused before buying.
• tagReservedNode uses the same ARN with CreateTags (lines332 and382). A post-purchase tagging error is logged while the successful purchase result is returned. The pre-purchase guard therefore depends on a marker whose supported write/read contract has not been established.

AWS's Redshift tagging guide enumerates supported resource types without reserved nodes. This is a documented-contract gap, not a claim that a live AWS request was executed or rejected. No purchase, tag mutation or credentialed cloud verification was performed.

Steps to verify the gap

1. Trace PurchaseCommitment through findNodeByIdempotencyToken, scanNodesForToken, nodeHasIdempotencyTag and tagReservedNode at the commit above.
2. Reconcile the exact ARN and resource type with AWS's current DescribeTags/CreateTags contract. Establish support from authoritative documentation or separately authorized read-only evidence; do not buy a reservation to test it.
3. Exercise the actual pre-purchase path with an existing active node and a nonempty idempotency token, including a tag lookup error. Exercise post-purchase tag failure and a re-drive without permitting a second real purchase.

Expected behavior and proposed fix

Use a supported, durable idempotency mechanism, and make the limits of post-purchase reconciliation explicit. If the tag API cannot support reserved nodes, replace that assumption at its source; do not suppress lookup errors or broaden IAM to imply the feature works. Confirm first that the chosen mechanism survives an interrupted purchase and cannot silently double-buy on retry.

Keep the provider behavior fix separate from PR LeanerCloud/cloud-commitments-cli#2077's six CE/EC2 runtime grants. Its proposed Redshift tag grants are being removed pending this contract verification. Update the related tests in providers/aws/services/redshift/client_test.go with actual error/re-drive shapes, not only happy-path tag mocks.

References and triage

• Found during PR LeanerCloud/cloud-commitments-cli#2077, which addresses fix(iac/aws): ce:GetCostAndUsage is granted in no IaC flavor; ladder baselines are denied cloud-commitments-cli#1967/#1968 and does not repair Redshift idempotency.
• Closed feat(purchases): extend IdempotencyToken to all commitment executors (AWS RDS/ElastiCache/MemoryDB/OpenSearch/Redshift, Azure, GCP) — blocks #639 cloud-commitments-cli#641 introduced the multi-service idempotency behavior; closed PR fix(purchases): recover executions stranded in 'approved' (closes #632) cloud-commitments-cli#635 addressed stranded execution recovery and does not prove this AWS tag contract.
• Open fix(aws): OpenSearch and Redshift idempotency guards page every reservation uncapped #87 concerns uncapped idempotency scans. Its proposed ResourceType: "reservednode" optimization must not be implemented without resolving this contract first.
• Open chore(aws): medium/low findings from the 2026-07-28 full review #53 tracks cached STS failures, and ARCH-03: AWS RI purchase skeleton (idempotency guard etc.) copy-pasted across 5-6 service clients #10 tracks duplicated purchase code; neither covers resource support for reserved-node tagging.

Severity: medium, limited Redshift users; priority P2 pending contract verification. Potential consequences include refusing legitimate tokened purchases or unreliable re-drive deduplication. No observed duplicate purchase is claimed. Effort M; investigate this sprint before adding tag grants or optimizing the tag scan.