CLI commands bind to an arbitrary site in multi-site installations

[t3-vfm]

Environment: EXT:lux 44.3.0, TYPO3 13.4, PHP 8.2, CLI.

Problem

All commands using ExtbaseCommandTrait bind their request to one single site, chosen
non-deterministically:

// Classes/Command/ExtbaseCommandTrait.php
$site = GeneralUtility::makeInstance(SiteService::class)->getDefaultSite();
$request = (new ServerRequest())
    ->withAttribute('applicationType', SystemEnvironmentBuilder::REQUESTTYPE_BE)
    ->withAttribute('site', $site)
    ->withQueryParams(['id' => $site->getRootPageId()]);

// Classes/Domain/Service/SiteService.php:51
public function getDefaultSite(): Site
{
    $sites = $this->siteFinder->getAllSites();
    return current($sites);
}

The docblock says "ordered alphabetical", but the order originates from SiteConfiguration
iterating the config/sites/* directory — filesystem order, effectively arbitrary and outside the
integrator's control.

Consequence

In a multi-site installation the commands resolve TypoScript for the root page of whichever site
happens to come first. If lux's static TypoScript is included in the template tree of a different
site, plugin.tx_lux_fe.settings is unresolvable and every command that reads settings fails.

There is no way to influence the choice: none of the commands offers a --site or --pid option.

We hit this with lux:leadSendSummary, where it surfaced as

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

PR #79 makes that failure understandable (a ConfigurationException naming the missing TypoScript
path instead of a TypeError), but it does not address the underlying site selection — hence this
separate report.

Worth noting

TYPO3's own fallback would behave more predictably. With no id in the request,
BackendConfigurationManager::getCurrentPageId() falls back to
getCurrentPageIdFromCurrentSiteRoot(), i.e. the first is_siteroot page ordered by sorting.
lux overrides that by setting id explicitly.

In our installation the TYPO3 fallback would have selected the correct site — which is why the lux
backend modules work fine while the CLI path fails.

Reproduction

1. TYPO3 13.4 with two sites, site-a and site-b; site-a comes first in config/sites/
   (verify with vendor/bin/typo3 site:list).
2. Include lux's static TypoScript only in the template tree of site-b.
3. vendor/bin/typo3 lux:leadSendSummary -- mail@example.org 86400 -1 0

Scope

All 11 commands using ExtbaseCommandTrait are bound to the same arbitrary site. The three
LuxLeadSendSummary* commands fail outright because they read TypoScript settings; the others may
silently operate in the wrong site context.

Possible directions

• A --site (or --pid) option on the commands, defaulting to the current behaviour.
• Or making getDefaultSite() deterministic and documenting the rule.

Footnote

identified = -1 cannot be passed on the command line without the -- separator — Symfony Console
parses -1 as an option (The "-1" option does not exist). The docblock example uses 1, so it
does not show this. Might be worth a note.