feat(plans): plan steps resolve real recommendations and show real counts and prices (tier B of #609) #631

Tier B of #609. The tier A stopgap (#618, #616, merged) made empty plan steps fail loudly and show "No recommendations attached". It did not make plans work: until this issue lands, no plan can complete a step, and "Add Purchases" always returns 409.

Goal

A plan created from recommendations (provider, service, term, payment, target accounts, target coverage, ramp) schedules steps that purchase real recommendations, and the planned-purchases list shows real counts, resource types, upfront cost and savings instead of placeholders.

Proposed shape

• Resolve the matching stored recommendations for the plan's provider, service, term, payment and target accounts at execution time, not at plan creation, so a step buys what is current when it runs.
• Size each step from the ramp: PercentPerStep of the resolved set, per the target-coverage meaning chosen under D1.
• Savings Plans steps are sized by HourlyCommitment, not instance count.
• Store the resolved recommendations on the execution, so approval, history and retry see the same rows.
• Planned-purchases preview: compute count, resource types, upfront and savings for pending steps from the current matching recommendations, labelled as an estimate until the step runs.
• Reuse createPurchaseExecutionsTx (ramp lock #1861, creator stamp sec(auth): API key permission constraints are silently dropped on create #950), which tier A kept without a production caller. Re-enable "Add Purchases" through it.
• Decide the dropped recommendations field of PlanRequest: honour it (per D2) or stop sending it from savePlan (frontend/src/plans.ts).
• Keep the tier A guards as the fallback: a step that resolves to nothing fails once and does not advance the ramp.

Open product decisions (block the design)

• D1. Does "target coverage 80%" mean "buy 80% of the matching recommendations" or "reach 80% account coverage"? The second needs a coverage source, which is unknown for Azure.
• D2. Is the snapshot sent by "Plan from N selected" binding, or does the plan filter win?

Known gaps to cover

• Recommendations with no account (Azure org-wide) never match a cloud_account_id = ANY(...) filter (buildRecommendationFilter). The step resolution must decide how to treat them, and the Opportunities page applies suppressions, account overrides and provider/allowed-account filters on top of the stored list; the plan path must match.
• Completed empty rows from before tier A already advanced the ramp. Count them with status='completed' AND recommendations='[]' AND plan_id IS NOT NULL; they are left in place.
• Auto-Purchase-OFF plans only reach execution through a manual approve/run.
• Dashboard still renders $0 for bare rows (fix(dashboard): upcoming purchases show zeros for plan steps with no recommendations #620).
• Azure costs feeding any preview depend on the go#267 unit fix being re-pinned (sec(azure): purchase spend caps and recorded Azure costs use lookback-window amounts (cap can be exceeded; stale rows after the fix) #612).

Acceptance

• A plan like the one reported (Azure compute, 1 year, 80% target coverage, weekly 25% ramp, one target account, Auto-Purchase on) produces steps with non-zero counts and real upfront and savings figures, and a scheduled step executes against real recommendations.
• A step with nothing to buy fails once, with one failed row, and the ramp does not advance.
• Regression tests use the real data shape of that plan and fail on current main.