Purchase a configured or recommended commitment

Executes the purchase of the referenced commitment. This single operation backs both UI triggers: the "Purchase commitment" confirmation at the end of the commitment creation form flow (finalizing a QUEUED draft) and the one-click "Purchase" button on an advisor recommendation card of the Commitments page (purchasing the recommended plan materialized as a QUEUED commitment). Purchasing charges any upfront amount per the payment option, locks the hourly committed rate for the term, and schedules activation; the resulting state is available to subsequent reads of the list and detail endpoints. A NO_UPFRONT purchase goes QUEUED → ACTIVE at once; an upfront-bearing (PARTIAL_UPFRONT|ALL_UPFRONT) purchase goes QUEUED → PENDING_ACTIVATION and opens a pending-manual-approval upfront charge — the commitment becomes ACTIVE only when Finance confirms that charge, and terminally REJECTED if Finance marks that charge never-received instead. Validation: the commitment must exist and be visible in the active scope (else 404 NOT_FOUND); its current state must permit purchase — only QUEUED commitments are purchasable, a PENDING_ACTIVATION, REJECTED, ACTIVE, EXPIRING or EXPIRED commitment maps to 409 CONFLICT; the caller must hold owner|admin|billing on the scope, else 403. Async & state: Conditionally asynchronous — returns 202 with an Operation (PENDING → RUNNING → SUCCEEDED|FAILED). On success the commitment transitions QUEUED → ACTIVE and a resource.updated SSE frame of kind billing.commitment is emitted (patch with status, startedAt, expiresAt, upfront); on payment failure the Operation terminates FAILED with an ApiError and the commitment remains QUEUED. Errors: 401 unauthenticated; 403 insufficient role; 404 unknown scope or commitment; 409 the commitment is not in a purchasable state or a purchase is already in flight; 422 malformed request; 500 internal failure. Idempotency/Concurrency: Idempotency-Key is optional (recommended) — replaying the same key returns the original 202 Operation and never double-charges. This operation does not check If-Match; a sent one is ignored (the state guard above refuses a commitment that is no longer QUEUED).