SWW_APPS: an app's Core Rule Set fixes apply only to the hostnames that serve it (closes #220)

Each app's fixes are one .conf file and one entry in apps. They apply
only while Inspect has set the app's transaction variable, such as
tx.app_gitea. SWW_APPS names each hostname's apps. A hostname gets only
its apps' fixes; while SWW_APPS is unset, every hostname gets every
app's fixes. Listing forgejo, a fork of gitea, brings gitea's fixes too.

A hostname in SWW_APPS that is not a DNS name, such as *.example.com,
stops the start. Unset, SWW_APPS is logged at start as null; set
empty, as "".

Model: opus-5-5

internal/coreruleset/vaultwarden.conf

@@ -1,4 +1,4 @@
-# The thirteenth change: on Vaultwarden's paths, some fields skip the rules that
+# Vaultwarden's fixes: on Vaultwarden's paths, some fields skip the rules that
 # refused ordinary Vaultwarden requests there. They are the fields where
 # Vaultwarden receives a name, a password hint or an email address in plain
 # text, and the names of uploaded files. Each exclusion runs with the request,
@@ -17,6 +17,13 @@
 #   932250: ls -la
 #   932260: python3
 
+# Unless SWW_APPS lists vaultwarden for the request's hostname, every rule below
+# is skipped. Inspect sets tx.app_vaultwarden when it does.
+# The skip reaches only phase 1, so a rule of a later phase must check
+# tx.app_vaultwarden itself.
+SecRule &TX:app_vaultwarden "@eq 0" \
+    "id:900140,phase:1,pass,nolog,skipAfter:END_VAULTWARDEN"
+
 # Names and password hints, in JSON bodies, skip the four rules:
 #   name: signing up, editing the account's profile, and creating or renaming
 #   an organization or a group, "python3 .htaccess team"
@@ -124,3 +131,5 @@ SecRule REQUEST_FILENAME "@rx ^/admin/?$" \
         ctl:ruleRemoveTargetById=942540;ARGS:token,\
         ctl:ruleRemoveTargetById=942550;ARGS:token,\
         ctl:ruleRemoveTargetById=944150;ARGS:token"
+
+SecMarker END_VAULTWARDEN