feat(webmail): pastas próprias na barra lateral e regras em linguagem comum

Regras. A tela pedia um tipo de correspondência do Sieve pelo nome -
:contains, :is, :matches (regex) - e colava o valor escrito
diretamente num script. Punha uma linguagem de padrões à frente de
quem só queria dizer "o que vem do banco vai para Faturas", e bastava
uma aspa no valor para o script deixar de fazer parse, desativando
silenciosamente todas as regras de uma vez.

O vocabulário passa a ser o de quem escreve: um campo, uma condição em
português, um valor e uma ação. Os curingas são gerados a partir de
"começa com" e "termina com" - ninguém os escreve, e um asterisco
escrito por acaso continua a ser um asterisco. A pasta de destino é
escolhida de uma lista das pastas que existem mesmo, em vez de ser
escrita à mão: antes uma regra podia nomear uma pasta inexistente e
nunca disparar, sem dizer porquê.

A ordem passa a ser visível e alterável, porque a primeira regra que
arquiva uma mensagem decide para onde ela vai.

Um script que esta tela não consegue exprimir - escrito à mão, ou por
um cliente de secretária sobre ManageSieve - é mostrado tal como está,
em vez de ser reescrito na coisa mais parecida que este formulário sabe
dizer, o que mudaria em silêncio o que o correio de alguém faz.

Pastas próprias. Existiam na base de dados e as regras podiam arquivar
nelas, mas a barra lateral listava só as seis fixas, portanto não havia
como ver uma - nem como criar. Criar fica onde a vontade aparece, na
própria barra; apagar avisa que leva as mensagens junto, porque leva.

Encontrado a escrever isto: o motor tratava "\\*" como barra seguida de
curinga em vez de um asterisco literal. Como é esta tela que gera os
curingas, uma regra sobre um assunto com "50% *" teria correspondido a
todos os assuntos começados por "50% ". Corrigido no motor, com testes
dos dois lados.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

services/webmail/src/mailCounts.test.ts

@@ -159,7 +159,7 @@ describe("marking a message read in the loaded list", () => {
 
 // --- what the sidebar actually renders -----------------------------------
 
-import { folderBadge, readerActions, moveTargets } from "./lib/mailCounts";
+import { folderBadge, readerActions, moveTargets, customFolders } from "./lib/mailCounts";
 
 /**
  * These reproduce what the running webmail shows, which the badgeCount tests
@@ -302,3 +302,34 @@ describe("where a message may be moved", () => {
     expect(moveTargets(folders, "sent").map((f) => f.name)).toContain("Archive");
   });
 });
+
+describe("the folders a user made themselves", () => {
+  const folders = [
+    { special_use: "inbox", name: "INBOX", unread_count: 0, total_count: 3 },
+    { special_use: "sent", name: "Sent", unread_count: 0, total_count: 1 },
+    { special_use: "trash", name: "Trash", unread_count: 0, total_count: 0 },
+    { special_use: "", name: "Reports", unread_count: 0, total_count: 2 },
+    { special_use: "", name: "Faturas", unread_count: 1, total_count: 4 },
+    { special_use: "", name: "Clientes", unread_count: 0, total_count: 0 },
+  ];
+
+  // The sidebar lists the standard folders from a fixed array, so a folder the
+  // user created appears nowhere unless it is picked out separately.
+  it("are the ones with no special-use role, minus the system's own", () => {
+    const names = customFolders(folders).map((f) => f.name);
+    expect(names).toEqual(["Clientes", "Faturas"]);
+  });
+
+  it("leaves out Reports, which this server fills itself", () => {
+    expect(customFolders(folders).map((f) => f.name)).not.toContain("Reports");
+  });
+
+  it("lists them in alphabetical order, since nothing else orders them", () => {
+    expect(customFolders(folders).map((f) => f.name)).toEqual(["Clientes", "Faturas"]);
+  });
+
+  it("copes with no folders at all", () => {
+    expect(customFolders([])).toEqual([]);
+    expect(customFolders(undefined)).toEqual([]);
+  });
+});