Update load balancer settings

Renames the load balancer. name is held by the provider (Octavia) as well as the platform, so a rename is an asynchronous provider change, not a metadata-only edit: the request is accepted with 202, a tracking operation loadbalancer.load_balancer.update is opened, and a worker renames the Octavia load balancer first and the platform record second. Until the operation settles, reads still return the old name; the 202 body is the load balancer as it will read once the rename is applied. A load balancer whose create never reached the provider has nothing to rename there, so only the platform record changes. The data-plane fields of the body (vipSubnet, vipAddress, flavor, listener, pool, monitor) are not yet supported and are rejected with 422 VALIDATION_FAILED rather than ignored. Validation: empty body → 422; load balancer must exist in scope (404); provisioning must not be PENDING_CREATE/PENDING_DELETE (409 CONFLICT); a load balancer in ERROR that exists in the provider is rejected with 409 CONFLICT (the provider refuses to modify it — delete it and create a new one); a data-plane field → 422 VALIDATION_FAILED. Async & state: Always asynchronous: 202 with the LoadBalancer. Poll the operation (or watch resource.updated SSE frames, kind "network.load_balancer") for SUCCEEDED / FAILED. Errors: 401 unauthenticated; 403 caller lacks contributor/owner/admin; 404 unknown LB; 409 state conflict; 412 missing or stale If-Match; 422 invalid fields; 500 backend failure. Idempotency/Concurrency: Idempotency-Key is optional; a retry with the same key and body replays the original 202, a different body under the same key is 409. If-Match is REQUIRED for this operation: send the ETag from the last read; a missing or stale value yields 412 PRECONDITION_FAILED.