fix(bimi): each domain's logo under its own URL, and the publisher actually wired

Two bugs found by the setup check right after the last deploy:

- every domain's BIMI record named the deployment's own mail host, and the
  server picked the domain from the host name, so only the primary domain's
  logo could be fetched: ciberlab.seg.br's record pointed at a 404. The logo
  and the certificate are now served at /.well-known/bimi/<domain>/..., the
  record names that, and the webmail routes it. The old path still answers
- SetBimiPublisher ran before SetBimiAPI, found no BIMI API to attach to and
  was dropped, so saving a logo never published the DNS record by itself. It is
  kept on the router now, so the order does not matter

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

README.md

@@ -226,7 +226,12 @@ everyone who sends from it. Publishing one needs three things, and the console
 file, DMARC, the BIMI record in DNS, the public URL of the logo, the
 certificate and its public URL, and names the one that is wrong.
 
-The logo is served from `https://<mail host>/.well-known/bimi/default.svg`.
+The logo is served from `https://<mail host>/.well-known/bimi/<domain>/default.svg`
+and the certificate from `.../<domain>/vmc.pem`: one mail host, a path per
+domain, so every domain the server hosts can publish its own. (The earlier
+`/.well-known/bimi/default.svg` chose the domain from the host name, which could
+name only the primary domain; every other domain's record pointed at a 404. It
+still answers, for records already published.)
 
 **The DNS record follows the picture.** With a Cloudflare token configured, the
 `default._bimi.<domain>` TXT record is part of what the DNS reconciler