Investigate scalable open data loading for PowerShell module

Summary

The Build-OpenData.ps1 script generates PowerShell functions from all CSV files in src/open-data/. Each CSV is converted into a Get-OpenData* function with inline [PSCustomObject] arrays that get dot-sourced on every module import.

With the addition of CommitmentDiscountEligibility.csv (~84K rows, 4MB CSV), the generated PowerShell file would be significantly larger than existing datasets. As more open data files are added or grow, this pattern may not scale well.

Potential approaches

• Lazy loading: Load CSV data on first use rather than at module import
• Runtime CSV import: Use Import-Csv at runtime instead of embedding data in code
• Exclude large datasets: Add filtering to Build-OpenData.ps1 to skip specific files
• Binary/compiled data: Use serialized data formats for faster loading

Context

• Raised during review of PR #2056 (commitment discount eligibility open data)
• Applies to all open data files, not just the new one
• Current datasets (PricingUnits, Regions, ResourceTypes, Services) are small enough that the impact is minimal
• No user complaints about current load times

Related

• PR #2056

Start by reading Build-OpenData.ps1 and inspecting the generated functions for the CSV files under src/open-data/, especially CommitmentDiscountEligibility.csv. Compare the listed loading approaches against current module-import behavior and dataset sizes. Done means selecting and implementing a scalable approach for all open-data files, with its impact and validation documented.