feat: site settings are edited in the backend, per environment

The constants of the sites become editable in Site Management >
Settings (admins only in TYPO3 13.4). settings.definitions.yaml of the
set ep/theme defines all 116 constants plus googleTagManagerId, with the
labels and categories of their constant editor annotations and today's
constants.typoscript values as defaults. Every setting is a string,
yes/no ones with a select of exactly '0' and '1': a bool setting would
hand '' instead of '0' to TypoScript.

config/sites/*/settings.yaml become shared files on the server and leave
git, like settings.php: production is leading, so backend edits survive
deploys, and each environment keeps its own values. Nine settings nobody
reads (twitterUrl, vimeoUrl, cookiefirstKey, ...) were dropped locally;
on production they stay in the seeded files until removed there.

deploy:check:site-settings aborts before anything else touches the
server if one of the shared files is missing or empty: deploy:shared
would create it empty, silently resetting that site to the defaults.

Rollout, after the site set is live: seed the shared files from the
live release once, then deploy:
  cd <deploy_path> && for f in current/config/sites/*/settings.yaml; do
    mkdir -p "shared/${f#current/}" && rmdir "shared/${f#current/}" &&
    cp -p "$f" "shared/${f#current/}"; done

Verified locally: the resolved setup of 43 pages is unchanged and only
the nine unused constants are gone (switched state); the root template
state is unchanged; all 1912 frontend URLs are identical.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

deploy.php

@@ -21,10 +21,16 @@ set('shared_dirs', [
     // Baseline of the MyE&P import: without it every deploy would trigger a full re-import
     'var/transient/ep_products_import',
 ]);
-// Not in git, production is leading (encryptionKey, install tool, backend changes)
+// Not in git, production is leading (encryptionKey, install tool, backend changes; the site
+// settings are edited in the backend's Settings module, one settings.yaml per site)
+set('site_settings_files', array_map(
+    static fn(string $config): string => 'config/sites/' . basename(dirname($config)) . '/settings.yaml',
+    glob(__DIR__ . '/config/sites/*/config.yaml')
+));
 set('shared_files', [
     'config/system/secrets.php',
     'config/system/settings.php',
+    ...get('site_settings_files'),
 ]);
 set('writable_dirs', [
     '{{typo3/public_dir}}/typo3temp/assets',
@@ -96,6 +102,16 @@ task('deploy:check:fileadmin', function () {
     }
 });
 
+// The same for a site's settings.yaml: an empty one silently resets the site to the default settings
+// (navigation, storage folders, ...). A new site's file is put in place by hand first.
+task('deploy:check:site-settings', function () {
+    foreach (get('site_settings_files') as $file) {
+        if (!test("[ -s {{deploy_path}}/shared/$file ]")) {
+            throw new \RuntimeException(parse("{{deploy_path}}/shared/$file is missing or empty"));
+        }
+    }
+});
+
 // current_path instead of the recipe's release_path, so it also works after a rollback
 task('typo3:cache:flush', function () {
     run('{{bin/php}} {{current_path}}/{{bin/typo3}} cache:flush');
@@ -104,6 +120,7 @@ task('typo3:cache:flush', function () {
 task('deploy', [
     'deploy:info',
     'deploy:check:fileadmin',
+    'deploy:check:site-settings',
     // Build locally first, so a failing build aborts before the server is touched at all.
     'deploy:build',
     'deploy:setup',