Change a volume's category (tier)

Moves the volume onto a different product category. Whether that is a provider operation depends on the deployment, and the rule is deliberately the SAME one storage.volume.create already uses: a category is programmed onto the provider only when this environment maps it to a volume type the provider actually advertises. So:

• both categories map to real, advertised and DIFFERENT provider volume types → a real provider retype, which the provider may satisfy by MIGRATING the volume to another backend. That migration copies the data, so the Operation can stay pending for as long as the copy takes; the volume keeps its identity and its id throughout.
• otherwise (nothing mapped, or both categories land on the same provider type) → a control-plane change only: the category and its price change, the provider is not called. This is not a silent no-op — it is the same degrade create performs, and a category that was ignored when the volume was created cannot coherently be enforced when it is changed. Validation: volumeId must exist in the scope (unknown → 404); the volume must be AVAILABLE — an attached volume is 409 CONFLICT, because a retype that turns into a migration cannot be performed under a live attachment in the general case; type must be a known category and must DIFFER from the current one (→ 422 VALIDATION_FAILED). Caller needs owner|admin|contributor. Async & state: Asynchronous — 202 with an Operation. type and the volume's price change on completion, emitted as a resource.updated SSE frame (kind storage.volume). Errors: 401; 403; 404; 409 volume not AVAILABLE; 412 If-Match mismatch; 422 unknown or unchanged category; 500 provider failure. Idempotency/Concurrency: Idempotency-Key is optional (recommended); If-Match guards against racing another mutation of the same volume.