feat(azure): wire payment_option to reservation billingPlanType (Azure RIs always bill upfront)

[cristim]

Gap

Azure Reserved Instance purchases always bill upfront regardless of the requested payment_option. The purchase body builder (providers/azure/services/compute/client.go, buildReservationBody) is called with opts.Source and opts.IdempotencyToken but never receives opts.PaymentOption, so Azure's reservation API sends no billingPlanType and defaults to upfront.

Impact

• A caller requesting no-upfront or partial-upfront for an Azure RI would silently get an upfront commitment (different cash-flow schedule than requested).
• Currently guarded, not honored: the CUDly MCP server (PR feat(mcp): CUDly MCP server for RI/SP/CUD purchases across AWS, Azure, GCP #1495) fails loud and rejects non-all-upfront Azure RI real purchases rather than silently mis-billing. So there is no active money-safety hole; this issue is to actually support the other billing plans.

Fix

• Thread opts.PaymentOption into buildReservationBody and map it to Azure's billingPlanType (Upfront vs Monthly) on the reservation purchase request. Azure reservations support Upfront and Monthly billing plans; map all-upfront -> Upfront, no-upfront/partial-upfront -> the closest supported plan (Monthly), or reject combinations Azure genuinely cannot express (fail loud, no silent default).
• Use the SDK's typed billing-plan enum, not a raw string literal (project convention).
• Once wired, remove the MCP tool's real-purchase rejection of non-all-upfront in mcp/tools/azure_compute_ri.go and let the value flow through.

Scope note

This is a provider-layer change that also benefits the CLI and web (internal/api) purchase paths, not just MCP. Verify against Azure's reservation billing-plan API surface before wiring; do not assume the mapping.

Related

• PR feat(mcp): CUDly MCP server for RI/SP/CUD purchases across AWS, Azure, GCP #1495 (MCP server) added the safe fail-loud guard this issue would lift.
• The retry-safety idempotency work for Azure landed earlier (issue bug(providers/azure): DoPurchaseTwoStep dropped IdempotencyToken threading; reintroduces double-purchase risk (regression of #641; blocks #639) #721).

[cristim]

Scope widened: the same billingPlan omission affects 6 sibling Azure services

The compute wiring is landing in PR #1495 (new helper reservations.BillingPlanForPaymentOption + billingPlan set in compute's buildReservationBody). An adversarial review confirmed the other six Azure reservation-based services build their own request bodies and never set billingPlan, so a no-upfront/monthly recommendation for any of them is still silently billed at Azure's Upfront default:

• providers/azure/services/database
• providers/azure/services/cache
• providers/azure/services/cosmosdb
• providers/azure/services/search
• providers/azure/services/managedredis
• providers/azure/services/synapse

Remaining work for this issue

Wire each of the six clients' reservation-body builders through the shared reservations.BillingPlanForPaymentOption helper (same pattern PR #1495 applied to compute), with a per-service test asserting the marshaled body carries billingPlan: Monthly for no-upfront and Upfront for all-upfront, and fails loud on empty/partial-upfront. Compute is done in #1495; this issue now tracks the remaining six.

[bughunter-dotcom]

I can take the six remaining Azure service clients as an assignment-first fixed scope for 120 USDC, delivered within 48 hours after escrow funding.

Proposed acceptance checklist:

• thread each service's requested payment option through the existing shared reservations.BillingPlanForPaymentOption helper for database, cache, cosmosdb, search, managedredis, and synapse;
• serialize the SDK's typed billing-plan enum into each reservation purchase body — Upfront for all-upfront, Monthly for no-upfront;
• preserve fail-loud behavior for empty/unsupported/partial-upfront values rather than allowing Azure's implicit Upfront default;
• add a table-driven or per-service body-marshalling test that proves both supported values and the rejection path for every client;
• run the affected provider tests plus go test ./..., and provide exact output;
• no Azure credentials, real reservations, or production purchases required.

Before implementation, please confirm:

1. assignment to bughunter-dotcom;
2. whether the branch should target current main or be based on open PR feat(mcp): CUDly MCP server for RI/SP/CUD purchases across AWS, Azure, GCP #1495 where the shared helper and compute reference implementation currently live;
3. that the remaining scope is exactly the six services listed in your follow-up;
4. a funded 120 USDC milestone and payout network.

Escrow option (LaborX, Base USDC): https://laborx.com/gigs/i-will-debug-and-fix-your-api-ci-or-qa-automation-with-tests-109222

Relevant deterministic test-delivery samples: https://github.com/bughunter-dotcom/resilient-http-client-sample and https://github.com/bughunter-dotcom/playwright-ci-sample

If direct fixed-USDC contracting is not available, no problem — I will not submit a speculative implementation.