Batch UI generation uses admin theme instead of default theme for all pages

Problem/Motivation

When generating a static site via the admin UI form (/admin/config/tome/static/generate), all generated pages use the admin theme (e.g. Claro, Gin) instead of the site's default frontend theme.

This does NOT happen when using drush tome:static.

Steps to reproduce

1. Configure an admin theme different from the default theme (e.g. admin: claro, default: my_custom_theme)
2. Generate a static site via /admin/config/tome/static/generate
3. Inspect the generated HTML files — they use the admin theme's markup/classes/libraries
4. Compare with drush tome:static output — correct frontend theme is used

Root cause

batch_process() in Drupal core's form.inc stores the active theme at submission time in $batch['theme']. The BatchNegotiator then returns this admin theme for all batch requests. Drupal's ThemeManager caches the active theme and only re-negotiates when it's NULL.

RequestPreparer::prepareForRequest() resets many state elements between sub-requests (context repository, path matcher, menu active trail, language, static caches, HTML seen IDs) but never calls ThemeManager::resetActiveTheme(). Since all Tome sub-requests execute within the same PHP process during the batch, the admin theme remains cached for every page rendered.

This doesn't affect CLI generation because there's no batch — ThemeManager starts with NULL active theme and negotiates correctly via DefaultNegotiator for each sub-request.

Proposed resolution

Inject ThemeManagerInterface into RequestPreparer and call $this->themeManager->resetActiveTheme() at the end of prepareForRequest(). This forces theme re-negotiation on each sub-request, allowing DefaultNegotiator to return the correct frontend theme.

Changes

• RequestPreparer.php: add ThemeManagerInterface property, constructor argument, and resetActiveTheme() call after Html::resetSeenIds()
• tome_static.services.yml: add '@theme.manager' as 7th argument to tome_static.request_preparer