Allow overriding Message-ID domain (avoid `@localhost.localdomain` in containers)

[bndrgroup]

Problem

When running listmonk in container platforms where the OS hostname is not a fully-qualified domain name (FQDN)—e.g. Azure Container Apps—outgoing email ends up with a Message-Id like:

Message-Id: <...@localhost.localdomain>

This looks unprofessional and can negatively impact deliverability (especially for new senders) even when SPF/DKIM/DMARC all pass.

From a real message received in Gmail (abridged):

Message-Id: <1770736902985131562.1.666377036005138658@localhost.localdomain>
From: email@mktg.domain.com
DKIM: pass
SPF: pass
DMARC: pass

Expected behavior

There should be a supported way to set/override the domain part used for generated Message-Id, e.g. @mktg.domain.com (or derived from an existing config like Root URL / sender domain).

Actual behavior

The Message-Id domain appears to come from the OS hostname (os.Hostname()), and if it’s not an FQDN it falls back to localhost.localdomain (this seems to be coming from smtppool).

Environment

•	listmonk version: v6.0.0 (00f303c2, linux/amd64)
•	Deployment: Azure Container Apps
•	SMTP provider: Azure Communication Services SMTP
•	Domain/sender: investors@mktg.domain.com
•	Auth: SPF/DKIM/DMARC all pass; deliverability impacted by Message-Id shape

Steps to reproduce

1.	Deploy listmonk in a container environment where the kernel hostname is not an FQDN (no dot), e.g. Azure Container Apps.
2.	Configure SMTP and send a test campaign.
3.	Inspect received email headers → observe Message-Id: ...@localhost.localdomain.

Proposed solution

Add a config option to override the Message-ID generation domain, e.g.:
• smtp.message_id_domain = "mktg.domain.com" (or similar)
• Alternatively derive Message-Id domain from app.root_url / configured sender domain when hostname is not a usable FQDN.

Implementation idea:
• When generating messages, if Message-Id is not already set, generate a unique ID and use the configured domain.
• This avoids relying on container hostname and removes the localhost.localdomain fallback for modern deployments.

Why this matters

This affects many users running listmonk in Kubernetes / serverless container platforms where setting an FQDN hostname isn’t possible. It also impacts deliverability and brand trust despite correct SPF/DKIM/DMARC alignment.

Related references
• Underlying behavior likely in knadh/smtppool Message-Id generation / hostname fallback.
• Similar reports exist for container environments (k8s, etc.)

#2146

[knadh]

The HELO hostname config that's available in SMTP settings currently (used by the HELO command), if set, could be used in Message-ID generation as well. This will require no changes to the UI, just a minor internal change to the smtppool lib.