Update a security group

Updates the mutable metadata of an existing security group from the detail view's "Edit" dialog ("Save changes"): the group name and description. Rules are managed through the dedicated security-rule sub-resource endpoints, not through this PATCH. The change is applied in place and immediately visible to subsequent reads; attached ports keep enforcing the same rule set under the new name. Validation: the security group must exist in the scope and not be soft-deleted → 404 NOT_FOUND; when name is supplied it must match ^[a-z0-9-]{1,63}$ → 422 VALIDATION_FAILED and be unique within the resource group → 409 CONFLICT; at least one updatable field must be present → 422; current resource state must permit update (no deletion in progress) → 409 CONFLICT. Async & state: Synchronous metadata mutation — returns 200 with the updated SecurityGroup; no transitional state. A resource.updated SSE frame is emitted for the security-group resource with a name/description patch so open list and detail views refresh. Errors: 401 unauthenticated; 403 caller lacks contributor rights; 404 unknown security group; 409 CONFLICT on duplicate name or when a concurrent delete is in flight; 412 when the supplied If-Match ETag no longer matches; 422 on field validation failure; 500 on persistence errors. Idempotency/Concurrency: This operation does not use Idempotency-Key; it may be omitted and a sent one is ignored. A repeated identical PATCH re-applies the same fields (same end state) and bumps the ETag, so resending a request that already succeeded with its original If-Match gets 412. If-Match with the ETag from the detail read is honored; a stale ETag yields 412 PRECONDITION_FAILED so lost updates are prevented.