Build CID attachment URLs against the API route and base path (#582)

* fix: build CID attachment URLs against the API route and base path

replaceCidReferences rewrote cid: references to /email/:id/attachment/:file,
which matches no route: attachments are served from the API server, mounted
at ${basePath}/api. When MailDev sits under a subpath the prefix was missing
as well, which is the setup described in #439.

Emit ${basePath}/api/email/:id/attachment/:file, root-relative by default, and
thread the API server's basePath through getEmailHtml. baseUrl still prefixes
//host for a caller that passes it.

On the current code this does not change what the web UI shows for a typical
message: mailparser already inlines related parts as data: URIs, and a cid:
that survives parsing is one that matches no attachment. replaceCidReferences
is exported from @maildev/smtp, though, so the URL it builds should resolve.

Refs #439

* fix: omit the base path prefix when it resolves to the root

A caller passing basePath '/' produced //api/email/..., which a browser reads as a protocol-relative URL rather than a path. Strip the slashes first and only add a prefix when something is left.

.changeset/fix-cid-attachment-url.md

@@ -0,0 +1,11 @@
+---
+'@maildev/smtp': patch
+'@maildev/api': patch
+---
+
+Fix the URL that `replaceCidReferences` rewrites inline (CID) attachments to. It
+built `/email/:id/attachment/:file`, which matches no route: the attachment is
+served from `/api/email/:id/attachment/:file`, under the configured base path.
+The URL is now root-relative and includes both parts, so it resolves at the root
+and under a subpath such as `/mail`. A base path that resolves to the root (`/`)
+adds no prefix, so it can no longer produce a protocol-relative `//api/email/...`.