fix(aws): OpenSearch and Redshift idempotency guards page every reservation uncapped

[cristim]

Summary

The pre-purchase idempotency guards in the OpenSearch and Redshift clients walk the account's entire reservation inventory with no page cap and no ctx.Err() check, unlike the offering scans in the same files, which carry maxOfferingPages. OpenSearch's findReservationByName pages DescribeReservedInstances (no name filter) until the list ends. Redshift's scanNodesForToken does the same over DescribeReservedNodes and additionally issues one DescribeTags round trip per active node. In an account with a large reservation history the guard consumes the Lambda budget purchasecfg was introduced to protect, and a throttled or slow call mid-scan surfaces as a lookup failure that blocks a legitimate first-time purchase. Blast radius is narrow: accounts with thousands of reservations or hundreds of active reserved nodes.

Location

• providers/aws/services/opensearch/client.go:242 (findReservationByName, called from idempotencyGuard at :275-285) at 3c0f8ac94048a2c36fce5ccddee54e6c4849a5cd
• providers/aws/services/redshift/client.go:260 (scanNodesForToken, outer loop at :237-252, called from findNodeByIdempotencyToken at :226-230) at 3c0f8ac94048a2c36fce5ccddee54e6c4849a5cd

Contrast: opensearch/client.go:378,403 (maxOfferingPages guard on the offering loop), providers/aws/internal/purchasecfg/config.go:32 (15s HTTPTimeout).

Failure scenario

OpenSearch: an account with 3,000 historical reservations. Every tokened purchase first pages 30 DescribeReservedInstances calls; under throttling the purchase fails with a deadline error attributed to PurchaseCommitment rather than to the guard.

Redshift: an account with 200 active reserved nodes. scanNodesForToken issues up to 200 sequential DescribeTags calls before every purchase, each with a 15s HTTP timeout in the worst case. One throttled DescribeTags in the middle of the scan returns an error from the guard, and findNodeByIdempotencyToken turns that into a refused purchase.

Evidence

func (c *Client) findReservationByName(ctx context.Context, name string) (string, bool, error) {
    var nextToken *string
    for {
        response, err := c.client.DescribeReservedInstances(ctx, &opensearch.DescribeReservedInstancesInput{
            NextToken:  nextToken,
            MaxResults: 100,
        })

arn := fmt.Sprintf("arn:aws:redshift:%s:%s:reservednode:%s", c.region, accountID, nodeID)
tagged, err := c.nodeHasIdempotencyTag(ctx, arn, token)
if err != nil {
    return "", false, fmt.Errorf("failed to read tags for reserved node %s: %w", nodeID, err)
}

Suggested fix

Add a page cap and a ctx.Err() check at the top of both loops, and fail loud when the cap is hit (a truncated guard must not report "not found" and let the purchase proceed). For Redshift, replace the per-node DescribeTags with a single DescribeTags call filtered by ResourceType: "reservednode" and the token tag value.

---

Found by the 2026-09-02 codebase audit, finding A07-015 (with A07-016), reported by one reviewer and independently
confirmed by a second. Full report: docs/audits/codebase-audit-2026-09-02.md.

[cristim]

A prerequisite contract check for the proposed Redshift optimization is now tracked separately in #107. AWS documents taggable Redshift resource types without reserved nodes; the current constructed reservednode ARN and proposed ResourceType filter need authoritative support before we optimize around them. This is a source/documentation gap, not an observed live AWS rejection. LeanerCloud/cloud-commitments-cli#2077 will not add tag grants to imply that contract works. No purchase or tag mutation was performed.