Reservation savings underreported due to min() price selection on duplicated reservation price keys

While validating reservation savings, I found cases where savings are lower than expected, and some rows that should be positive appear as zero.

Root cause appears to be in reservation price lookup aggregation:

For the same lookup key, there can be duplicate price rows (for example Production and Dev/Test variants).
Current logic uses min for unit price selection.
In these duplicates, min tends to pick the lower Dev/Test price.
That underestimates the on-demand baseline and leads to underreported reservation savings.

👣 Repro steps
Compare outcomes with:
current aggregation using min
alternative aggregation using max
Observe that min picks the lower Dev/Test variant and produces lower savings totals plus more zero rows.

🤔 Expected
When duplicate price variants exist, reservation savings should use the correct production baseline price for comparison, not the lower Dev/Test variant.

🔧 Environment
FinOps hub version: affected in v1_0 and v1_2 transformation paths
Billing account type: observed in MCA scenario

ℹ️ Additional context
Proposed fix:

In reservation reference price summarize:
change ListUnitPrice from min to max
change ContractedUnitPrice from min to max
Why this fix:

Duplicate rows include Dev/Test and Production variants.
min can select Dev/Test (lower) and distort savings.
max selects the expected production baseline in those duplicate scenarios.