Renew a commitment (queue a successor term)

Renews the selected Commitment (the "Renew" action on the commitment detail page). Renewal creates a successor Commitment (renewedFromId = the path commitment) that copies its locked economics (type, term, payment option, scope, hourly committed rate, discount, upfront) and starts at max(now, expiresAt) of the path commitment, so coverage can continue without an on-demand gap. The renewed commitment itself is never changed — its expiresAt does not move; its renewalId now points at the successor. Payment gate: a successor with an upfront amount is PENDING_ACTIVATION and covers nothing until a platform operator confirms the linked upfront charge (a charge Transaction carrying the successor's commitmentId); its term then starts at max(confirmation, expiresAt of the renewed commitment). A NO_UPFRONT successor is ACTIVE immediately but covers usage only from its start. Result: 202 with a SUCCEEDED Operation whose resourceId is the successor's id (not the path commitment). Validation: the commitment must exist and be visible in the active scope (else 404 NOT_FOUND). 409 CONFLICT when its status is not ACTIVE, EXPIRING or EXPIRED (QUEUED, PENDING_ACTIVATION, REJECTED), when its term has not started yet (a queued renewal cannot itself be renewed), or when it already has a live renewal (renewalId set — pending payment or scheduled). Caller must hold owner|admin|billing on the scope, else 403. Errors: 401 unauthenticated; 403 insufficient role; 404 unknown scope or commitment; 409 see above; 422 malformed request; 400 IDEMPOTENCY_KEY_REQUIRED when an API token or service-account caller sends no Idempotency-Key; 500 internal failure. Idempotency/Concurrency: Idempotency-Key is required; replaying the same key returns the same successor (202, same resourceId) instead of creating a second renewal — also after that successor was REJECTED (renew again with a new key). Concurrent renewals of one commitment are serialised; at most one live successor can exist.