api: fetchCommitmentPurchases swallows store errors into zeroed dashboard KPIs

[cristim]

Found during the #1221 pre-merge review (pre-existing, not introduced there): handler_dashboard.go's fetchCommitmentPurchases logs store errors but returns zeroed commitment KPIs ("log error but don't fail") - a silent fallback on a money-visible path. A store outage silently shows $0 active commitments / committed-monthly on the dashboard instead of an error state. Fix: propagate the error (or an explicit degraded marker the frontend renders as unavailable, never 0). Per feedback_no_silent_fallbacks / nullable-not-zero.

[cristim]

Reviewed commit: be11bdcb5. Note: origin/main moved to 3e9660d06 during the review; re-verify against current main before changing code, since a finding may have been fixed or moved.

Re-derived independently during the 2026-07-28 full review of internal/api and confirmed still live on be11bdcb5. Recording as evidence, plus one compounding effect the issue does not mention.

Where, on current line numbers: internal/api/handler_dashboard.go:634-643 (fetchCommitmentPurchases), consumed at :678-683. On a GetActivePurchaseHistory error the function logs "KPIs will be zeroed" and returns (nil, false); calculateCommitmentMetrics then returns 0, 0, 0, nil and the handler ships a 200.

The compounding effect. calculateCurrentCoverage (internal/api/handler_dashboard.go:738) returns 100.0 whenever potentialSavings == 0. So a store error that zeroes the commitment half, occurring alongside a recommendations shortfall that zeroes the potential-savings half, renders "100% coverage, $0 committed": internally self-consistent, entirely fabricated, and reassuring rather than alarming. An operator with 400 active commitments sees a headline of zero commitments and zero YTD savings on a Monday-morning dashboard load, with a coverage figure that appears to confirm nothing needs buying.

Whichever fix is chosen (propagate the error, or an explicit degraded marker), the potentialSavings == 0 branch of calculateCurrentCoverage should be addressed in the same change, otherwise the degraded state still renders a confident 100%.

Sibling from the same review: internal/api/handler_inventory.go:224-230 has the same silent-fallback shape with a different wrong value. There, a failed ListRecommendations leaves onDemandByKey empty and coveragePct(covered, 0) computes covered/(covered+0)*100 = 100, so the Coverage tab renders 100% for every provider/service row. It is recorded in the grouped medium/low issue for internal/api from this review; the two are worth fixing together since they share the "zero is not the same as unknown" requirement (feedback_no_silent_fallbacks / nullable-not-zero).