Fix: send mailto unsubscribe ourselves instead of via the OS handler

The List-Unsubscribe action for mailto: links created a hidden anchor,
clicked it and reported success. That hands the mailto: URL to the OS
default mail handler - for a webmail user that opens the wrong program
or nothing at all, and the unsubscribe message is never sent, while the
banner still claims it was.

The confirm flow now parses the mailto: URL (address, subject, body -
percent-decoded manually since RFC 6068 does not use plus-encoding) and
sends the message through the account's own JMAP client, preferring the
identity that received the newsletter so the list can match the
subscriber. In unified views the send is routed to the email's owning
account. Success is only reported once the server accepted the message.

The mobile confirm dialog reused the success strings as its question
text; it gets proper confirm_message strings in all 22 locales, and
success_mailto now says what actually happened.

locales/pt/common.json

@@ -434,7 +434,9 @@
       "confirm_button": "Confirmar",
       "cancel": "Cancelar",
       "success_http": "Página de cancelamento aberta em nova aba",
-      "success_mailto": "Solicitação de cancelamento enviada para seu cliente de e-mail",
+      "success_mailto": "E-mail de cancelamento enviado",
+      "confirm_message_http": "A página de cancelamento será aberta em uma nova aba.",
+      "confirm_message_mailto": "Um e-mail de cancelamento será enviado ao remetente.",
       "error": "Não foi possível cancelar a inscrição",
       "dismiss": "Dispensar"
     },