fix(aws/ladder): computeEC2CoveragePct blends non-EC2 pool keys into reported EC2 coverage #37

Bug

computeEC2CoveragePct in providers/aws/ladder/layer_states.go (~lines 290-302) assumes "EC2 pool keys are exactly region:instance_type (one colon)" and only excludes RDS keys by checking for extra colon segments (engine/deployment). However, GetRICoverageMap in providers/aws/recommendations/coverage.go fans out to 5 non-RDS services (EC2, ElastiCache, OpenSearch, Redshift, MemoryDB), all using the same one-colon poolKey(region, instanceType) shape, e.g.:

• us-east-1:cache.m5.large (ElastiCache)
• us-east-1:m5.large.search (OpenSearch)
• us-east-1:dc2.large (Redshift)
• us-east-1:db.r6g.large (MemoryDB uses RDS-like instance types too)

These non-EC2 pools currently pass computeEC2CoveragePct's one-colon filter and get blended into what's reported as "EC2 RI coverage" (LayerState.CoveragePct for ladder.LayerConvertibleRI).

Impact

No engine decision currently consumes CoveragePct (confirmed during the LeanerCloud/cloud-commitments-cli#1479 review), so today's impact is a wrong reported metric only, not a live money-affecting decision. Lower priority than the RI utilization SERVICE+REGION filter fix in LeanerCloud/cloud-commitments-cli#1479 (which does affect a live reshape/exchange trigger).

Suggested fix

Distinguish EC2 pools positively rather than by exclusion, e.g.:

• Exclude instance types with cache./db. prefixes and .search/Redshift node-family patterns, or
• Key the coverage map by service so EC2-only pools can be fetched/filtered directly (cleaner, avoids an ever-growing exclusion list as more services are added to coverageServiceFilters).

Related

Follow-up from LeanerCloud/cloud-commitments-cli#1479 (which fixed the higher-severity sibling finding: GetRIUtilization blending utilization across all reserved-resource types and regions).