labels

O submódulo Labels gerencia `inbox_label`, um catálogo de rotulagem por conta associado a mensagens por meio de `inbox_message_label`. Cada label tem um `name` único dentro da conta à qual pertence (imposto no nível do serviço com uma verificação `findFirst` + `ConflictException`, não por uma restrição de banco de dados), uma `color` opcional e um `system_type` opcional (`inbox` | `sent` | `archived` | `trash` | `spam`) que permite que um label funcione também como marcador semântico, em vez de uma tag puramente cosmética — embora nada na lógica atual do serviço trate `system_type` de forma especial além de armazená-lo e ordenar por ele (`list` ordena por `system_type asc` antes de `id desc`, agrupando os labels com system_type primeiro).

`PATCH /inbox/labels/:id` tem propósito duplo, distinguido apenas por o corpo da requisição incluir ou não um `threadId`. Sem ele, comporta-se como uma atualização comum de campos (name/color/systemType/accountId, todos opcionais via `PartialType`). Com um `threadId`, ele ignora os demais campos por completo e, em vez disso, alterna a presença do label em todas as mensagens daquela thread (restritas às contas acessíveis ao chamador): verifica se alguma mensagem da thread já carrega o label via `inbox_message_label` e, em caso afirmativo, remove-o de todas elas; caso contrário, adiciona-o a todas — uma única ação idempotente de "aplicar/remover este label nesta thread", em vez de uma alternância granular por mensagem. O campo `toggled` da resposta reflete o estado resultante (`true` se o label acabou de ser aplicado, `false` se acabou de ser removido), e `applied: false` é retornado sem nenhuma escrita quando a thread não tem mensagens dentro das contas acessíveis ao chamador.

Excluir um label é um soft delete apenas em `inbox_label` — as linhas de junção `inbox_message_label` são deixadas no lugar em vez de serem limpas, e o `ON DELETE CASCADE` no nível do banco de dados naquela chave estrangeira nunca dispara, porque a própria linha do label nunca é fisicamente excluída. Isso é seguro porque toda consulta downstream que expõe labels (em particular as consultas de lista e detalhe de thread do submódulo Threads) filtra explicitamente `l.deleted_at IS NULL` ao fazer o join por `inbox_message_label`, de modo que um label em soft delete simplesmente deixa de aparecer em qualquer lugar na UI sem exigir um job de limpeza.