List-scoped default From address for campaigns and generated opt-in confirmations

[rjackson-erinos]

Is your feature request related to a problem? Please describe.

On a multi-sender instance (one listmonk serving many lists that each send as a different From identity), the campaign From is free text and nothing validates it against the campaign's target lists. A campaign for list A can be sent with list B's From — and it sends successfully, correctly signed, with no error anywhere. At a handful of lists that's a procedural check; at tens of sender identities it stops being survivable. The same gap was raised from the multi-user angle in #2258 (and its comments ask for exactly the per-list variant), and earlier in #890.

Generated double opt-in confirmation campaigns have the same problem in a sharper form: they always send from the global app.from_email, even when the list plainly belongs to a different sender (also the pain behind #3155 and the last comment on #890).

Describe the solution you'd like

An optional per-list default From address:

• When a campaign's selected lists carry one, the editor pre-fills (or derives) the From from the list instead of serverConfig.from_email.
• The multi-list objection that closed Per-list default from address option #890 ("a campaign can have multiple lists, so a per-list default isn't meaningful") resolves cleanly in practice: selected lists that agree derive that From; selected lists that disagree are a validation error naming both values. A send spanning two different sender identities has no valid single From anyway, so blocking it is the correct behaviour, not a limitation.
• Lists with no From configured keep today's behaviour (global default).
• Generated opt-in campaigns take the list's From, so the confirmation mail — the first message a subscriber ever receives — comes from the sender they subscribed to.

Describe alternatives you've considered

We run this today as a small patch set on v6.2.0: the mapping stored per list, the editor deriving and showing the From read-only, and a server-side check in validateCampaignFields (single choke point for create/update/test, covers API and scripted sends; makeOptinCampaignMessage derives the From for generated opt-in campaigns). It has held up well in real use, including the conflict-blocking rule. Happy to share the design or details.

Aware from CONTRIBUTING that admin-frontend PRs are on hold until the v7 UI, so this is filed as a request rather than a PR — mainly for consideration in the v7 server-rendered UI, where the backend half (derive + validate in validateCampaignFields) is independent of any frontend.