feat(recommendations): per-rec seeding inside multi-account fan-out buckets #197

Context

Issue #111 sub-option (ii) — per-bucket Payment seeding in the fan-out modal — landed in PR #193. The seed walks (provider, service, term) buckets and pulls each one's per-account AccountServiceOverride.payment when all recs in the bucket share one cloud_account_id. When a bucket spans 2+ distinct cloud_account_id values, no single account's override applies cleanly, so the bucket falls back to the toolbar Payment.

The fallback is documented and correct (toolbar's "Payment" is what the user explicitly clicked) — but it's also the only case where the user's per-account override silently has no effect on a bulk purchase. For accounts with strong policy preferences (e.g. "this account only does no-upfront"), bulk-purchasing across that account + others ignores the policy.

What needs to happen

Pick one of two designs:

A) Sub-divide buckets by account

The current bucket key is (provider, service, term). Adding cloud_account_id to the key would produce per-account buckets, each cleanly eligible for its own override seed. Trade-off: more buckets = more approval emails for the user (one per bucket already).

B) Per-rec dropdowns inside a multi-account bucket

Keep the bucket boundary as today, but render per-rec Payment dropdowns inside the bucket section when it spans multiple accounts. Trade-off: more complex UI; users have to think harder about a bulk purchase.

Likely lighter-touch: (B) for visibility, with a "split bucket by account" affordance for users who'd prefer (A)'s clean per-account audit emails.

Acceptance criteria

• A test in frontend/src/__tests__/recommendations.test.ts covering a multi-account bucket where each rec gets its own per-account override default.
• The fan-out modal renders the chosen UX (sub-divided or per-rec).
• getFanOutBuckets() / handleFanOutExecute reflect the user's per-account choices in their POST bodies.

References

• PR feat(recommendations): per-account service override pre-populated at purchase time (#111, ii+iii) #193 — landed (ii); the multi-account fallback is in resolveBucketPaymentSeed in frontend/src/recommendations.ts, with a TODO(verify recommendations engine actually consumes per-account service overrides #111-followup) breadcrumb comment.

Effort & priority

• Effort: S-M (frontend-only; no backend changes)
• Priority: P3 (cosmetic — toolbar fallback is correct, just unsurprising for accounts with strong override policy)