[BUGFIX] Throw a speaking exception on missing summary mail settings

[t3-vfm]

What

ConfigurationService::getTypoScriptSettingsByPath() returns an empty string when the given path
cannot be resolved. SendSummaryService used that return value as an array:

$configuration = $this->configurationService->getTypoScriptSettingsByPath('commandControllers.summaryMail');
return [$configuration['fromEmail'] => $configuration['fromName']];

which fails with

TypeError: Cannot access offset of type string on string
in Classes/Domain/Service/Email/SendSummaryService.php line 62

The configuration is now resolved once, validated, and reused by getSender(), getSubject() and
getMailTemplate(). A missing configuration raises a ConfigurationException naming the TypoScript
path that has to be included.

Why it matters

The TypeError points at SendSummaryService instead of the actual cause: the static TypoScript of
EXT:lux is not part of the TypoScript template of the site the command runs against.

Multi-site installations run into this easily, because ExtbaseCommandTrait::initializeExtbase()
binds the request to SiteService::getDefaultSite() — which is current($siteFinder->getAllSites()),
i.e. the first site in filesystem order, not necessarily the site lux is configured for. Tracking
down the real cause from that error message takes a while.

Behaviour change

getSubject() and getMailTemplate() previously fell back to an empty string when the whole
configuration branch was missing, producing a mail with an empty subject or an unresolvable template
path. They now raise the same ConfigurationException. Individual missing keys still fall back to
an empty string via ??, so partial configurations behave as before.

Verified

Against 44.3.0 in a TYPO3 13.4 / PHP 8.2 installation:

• without the TypoScript: ConfigurationException with the path in the message, instead of the
  TypeError
• with the TypoScript: summary mail for 12 leads rendered and sent as before, correct subject and
  sender

Related

The non-deterministic site selection in SiteService::getDefaultSite() is the second half of this
problem and is reported separately in #80 — this PR only makes the failure understandable.