DLP and mail flow rules: inbuxa:MailRule over JMAP, and its permissions

Phase 2e of the DLP and mail flow rules spec, the API half.

- inbuxa:MailRule/get and /set under urn:inbuxa:jmap. Rules convert
  through serde, so what a client sends is the stored format. A create
  or change is validated whole (Rule::validate) and refused with the
  property at fault; id, createdBy, createdAt and updatedAt are the
  server's. Every change goes through the request layer's audit record.
- Six permissions, ids 674-679 (enum and schema labels): mail flow rules
  (sysMailRuleGet/Update), DLP rules (sysDlpPolicyGet/Update) and held
  mail (sysDlpReviewGet/Update, for phase 3). Either kind's permission
  gets through the gate; the handler shows and changes each rule only
  with its own kind's. All server-level: a tenant is refused (settled
  answer 3).
- Administrators get all six; the server-level Compliance Officer gets
  DLP rules to see and held mail to review (settled answer 4), added
  once to an existing server's officer role by the grant mechanism,
  which gains an officer audience.
- Privacy catalog entry for inbuxa:MailRule.

tests/src/system/mail_rules.rs: create, list in order, validation,
server-set properties refused, update, kind-separated permissions for
an officer, destroy, audit records.

crates/jmap/src/api/request.rs

@@ -279,6 +279,9 @@ impl RequestHandler for Server {
                                     SetResponseMethod::LegalHold(set_response) => {
                                         set_response.update_created_ids(&mut response);
                                     }
+                                    SetResponseMethod::MailRule(set_response) => {
+                                        set_response.update_created_ids(&mut response);
+                                    }
                                     SetResponseMethod::HoldExport(set_response) => {
                                         set_response.update_created_ids(&mut response);
                                     }
@@ -486,6 +489,11 @@ impl RequestHandler for Server {
                     resolve_account_id(&mut req.account_id, method_name.obj, access_token)?;
                     crate::inbuxa::legal_hold::get(self, *req).await?.into()
                 }
+                // inbuxa: DLP and mail flow rules
+                GetRequestMethod::MailRule(mut req) => {
+                    resolve_account_id(&mut req.account_id, method_name.obj, access_token)?;
+                    crate::inbuxa::mail_rule::get(self, access_token, *req).await?.into()
+                }
                 // inbuxa: the audit log (AU-9)
                 GetRequestMethod::AuditEvent(mut req) => {
                     resolve_account_id(&mut req.account_id, method_name.obj, access_token)?;
@@ -910,6 +918,22 @@ impl RequestHandler for Server {
                     .await?
                     .into()
                 }
+                SetRequestMethod::MailRule(mut req) => {
+                    resolve_account_id(&mut req.account_id, method_name.obj, access_token)?;
+                    let reason = req.arguments.reason.clone();
+                    crate::inbuxa::audit::recorded(
+                        self,
+                        access_token,
+                        session,
+                        &method_name.obj.to_string(),
+                        None,
+                        reason,
+                        *req,
+                        |req| Box::pin(crate::inbuxa::mail_rule::set(self, access_token, req)),
+                    )
+                    .await?
+                    .into()
+                }
                 SetRequestMethod::AuditExport(mut req) => {
                     resolve_account_id(&mut req.account_id, method_name.obj, access_token)?;
                     crate::inbuxa::audit_log::export_set(self, access_token, session, *req)