Add a security rule to a group

Adds a single rule to an existing security group via the detail view's "Add rule" dialog (available from the header and the inbound/outbound tab "Add" buttons). The dialog offers preset chips (SSH, HTTP, HTTPS, MySQL, PostgreSQL, RDP, DNS, Custom) that pre-fill the fields client-side; the submitted payload is always the concrete rule: direction (Inbound/Outbound), ether type (IPv4/IPv6), protocol (tcp/udp/icmp/any), port range (Port from / Port to — disabled and null for icmp/any), source/dest CIDR or a remote security-group reference, and an optional description. Once applied, the rule is enforced on every port attached to the group. Validation: the parent security group must exist in the scope and not be DELETING → 404 NOT_FOUND / 409 CONFLICT; direction, etherType and protocol must be valid enum values → 422 VALIDATION_FAILED; for tcp/udp, portMin and portMax must be integers 1-65535 with portMin <= portMax → 422; for icmp/any, portMin/portMax must be null → 422; exactly one of remoteCidr (valid CIDR, family matching etherType) or remoteGroup (an accessible security group in the scope) must be set → 422; an identical rule already present or the rules-per-group quota exhausted → 409. Async & state: Asynchronous — returns 202 with an Operation handle; the rule is persisted immediately and propagated to attached ports in the background. resource.updated SSE frames are emitted for the parent security-group resource with a rules-array patch (new rule appended) plus operation.updated frames until propagation reaches the terminal applied state. Errors: 401 unauthenticated; 403 caller lacks contributor rights; 404 unknown parent group; 409 QUOTA_EXCEEDED when the rules-per-group quota is exhausted (identical duplicate rule → 409 CONFLICT); 422 on any field validation failure; 500 on propagation workflow errors. Idempotency/Concurrency: Idempotency-Key is required; replaying the same key returns the original 202 Operation without inserting a duplicate rule.