fix(purchase): refuse a second ElastiCache purchase of the same pool inside one execution #1867

Follow-up from the plan for #1863 (the ElastiCache recent-reservation check), decision Q4.

The #1863 check refuses a recommendation when a recent reservation for the same pool already covers it. It does not protect against two recommendations for the same pool inside one execution (a duplicated Cost Explorer recommendation, or two plan-step recs for the same node type, region and engine):

• Each rec gets its own idempotency token (the index differs, internal/purchase/execution.go around :835), so the library guard sees two different reservation IDs.
• The per-rec checks run concurrently under the fan-out, so neither check can see the other's purchase.
• The check also drops every rec's own reservation ID of the same execution from its listing, so an own reservation never blocks a sibling.

Both recs therefore pass and both buy.

Proposed change

Before the fan-out, collapse same-pool recs of one execution (one rec per node type, region and engine pool per run). The plan needs a clear rule for which rec wins and for how counts combine, and the refused recs need a before-submission note that says why. Needs the owner's call on the rule (keep the first, sum the counts, or refuse the whole execution).

Acceptance

• An execution carrying two same-pool ElastiCache recs submits at most one purchase for that pool.
• Recs for different pools are unaffected.
• A test through the real executor path fails without the change.

Part of #1863.