feat(recommendations): option-B read-time filter for enabled / coverage / include-exclude per-account override fields

[cristim]

Context

Issue #111 verified that per-account account_service_overrides are read by ZERO call sites in the recommendations / scheduling pipeline (every override row is decorative until consumed). The user-approved fix landed in PR #193 — overrides now pre-populate the purchase forms (sub-options ii + iii: per-bucket Payment in the fan-out modal, and per-row Term/Payment in the single-bucket modal). Recommendations themselves stay unfiltered, by design.

That leaves the other override fields still decorative:

• enabled (when set to false, recs for that account/service should be hidden)
• coverage (per-account target % — affects what's "remaining" to recommend)
• include_engines / exclude_engines
• include_regions / exclude_regions
• include_types / exclude_types
• ramp_schedule

These all shape what the engine should list / aggregate for an account — not what to do at purchase time. Pre-populating purchase forms with payment doesn't move the needle for any of them.

What needs to happen

Wire per-account override lookup into the recommendations read path (option B from the issue #111 architectural fork):

1. Extend RecommendationFilter (internal/api/recommendations.go and friends) with account-aware predicates.
2. ListStoredRecommendations (and any sibling that backs the dashboard aggregator) consults account_service_overrides per row's cloud_account_id and applies:
   • enabled = false → skip the account's recs entirely for that service.
   • include_engines / exclude_engines (and the region / type pairs) → drop non-matching rows.
   • coverage → cap the headline "potential savings" to the configured target (related to follow-up issue on dashboard accuracy).
3. Frontend: when the user has the per-account-override panel open and changes a filter field, trigger a recommendations refresh (or invalidate the cached visible set).
4. Integration test that mirrors the original verify recommendations engine actually consumes per-account service overrides #111 acceptance criterion: seed a global ServiceConfig + a per-account override; trigger collection / list; assert the listed recs reflect the override.

References

• Issue verify recommendations engine actually consumes per-account service overrides #111 — original verification pass + architectural fork analysis
• PR feat(recommendations): per-account service override pre-populated at purchase time (#111, ii+iii) #193 — implements (ii) + (iii) at the purchase-time surfaces
• internal/config/resolver.go::ResolveServiceConfig — the merge helper that's currently dead code; this is the function the read path should consult per-account
• internal/api/handler_recommendations.go::ListRecommendations — likely main edit point
• internal/scheduler/scheduler.go:585-598 — collection-time read of globalCfg.DefaultTerm/DefaultPayment (out of scope for this issue; option A territory)

Effort & priority

• Effort: M (touches read API, dashboard aggregator, frontend cache invalidation, tests)
• Priority: P1 (deferred from verify recommendations engine actually consumes per-account service overrides #111; until this lands, the override panel is half-decorative — only payment does anything)

Out of scope

• Collection-time filtering (option A from verify recommendations engine actually consumes per-account service overrides #111). This issue is about read-time / aggregate-time only — caches stay full so the comparison view ("what would 1yr-no-upfront save instead?") remains available.
• Backend SDK / client changes for the cloud APIs themselves.

[cristim]

PR #200 landed on feat/multicloud-web-frontend (commit chain 4545194..e8ce3fe) and ships all four sub-tasks from this issue:

• enabled = false → drops the account+service's recs from Scheduler.ListRecommendations.
• include_engines / exclude_engines (and the region / type pairs) → drop non-matching rows.
• coverage → caps the dashboard "potential savings" headline per-account in summarizeRecommendationsWithCoverage.
• Frontend: every override-panel mutation triggers a recommendations refetch via refreshRecommendationsAfterOverrideChange.

The acceptance test mirrored from #111 (seed global + per-account override → assert listed recs reflect it) lives at internal/scheduler/scheduler_overrides_test.go::TestApplyAccountOverrides_AcceptanceCriterion_Issue196.

Recommend closing. Out-of-scope follow-ups remain available to file if needed:

• Detail endpoint refactor (getRecommendationDetail → direct by-id store lookup so deep links to filtered recs don't 404).
• Coverage-aware rec generation (referenced from this issue's "follow-up on dashboard accuracy").
• ResolveServiceConfig nil-global hardening (callers currently work around with a pre-check).

[cristim]

Closed by PR #200 (the body's Closes #196 reference didn't auto-link, hence the manual close).

Verified via the issue #111 wrap-up smoke today: the read-path filter wires through correctly to the recommendations list and the per-account coverage scaling on the dashboard. The follow-up dashboard headline polish lives in #199.