fix(R-1187): the import's compose runs get the controller's path variables; a compose warning is never read as the container id

Found live on 9202 (grimmory import timed out on the DB step and left the app down). Red-proved.

CHANGELOG.md

@@ -47,6 +47,12 @@ hub answers 400 to both and nothing else changes.
   A third review finding: a link TARGET through a link already in the folder („x" → „evil/y", evil pointing out). The rule
   is now strict and simple: a restored link points only DOWNWARD — relative, no „..", no link on its path or in its
   target; everything else is refused and listed (`safeDownwardLink`; `TestR1187b_NoLinkTargetThroughALink`, red-proved).
+  **Found live on 9202 the same night (grimmory), fixed:** the import ran `compose` without the controller's own path
+  variables (`USERDATA_PATH`, `IMPORT_PATH` — `stacks.policyEnv` adds them at every install and start); compose printed
+  „The USERDATA_PATH variable is not set" and the DB step read that WARNING as the container id, waited 60 s and left the
+  app removed and not started. Now `withImportPathVars` gives the import's compose runs the same derivation (never a
+  bundle's value) and `containerIDFrom` takes only a line that IS an id. Tests `TestR1187_TheContainerIDIsNeverAComposeWarning`,
+  `TestR1187_TheImportEnvCarriesTheControllersPathVars`, red-proved.
 - **R-1298:** the hold report skips an install's hold (`unhealthy_stop`, `update_failed`, `putback_pending`) of an app that
   is not installed (`holdreport.Reporter.SetInstalled`: the app's `app.yaml` exists — an unreadable one still counts,
   R-1220) and reports it cleared if it was reported; a restore hold is always reported (R-379). 9202's four orphan holds