fix(R-1187): the .fab import loads the database through the backup side (mariadb-admin/mariadb, the container's own credentials)

Found live on 9202: every MariaDB 11+ import timed out (mysqladmin/mysql absent). Red-proved.

CHANGELOG.md

@@ -53,6 +53,13 @@ hub answers 400 to both and nothing else changes.
   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.
+  **And the second cause, found by the same live run:** the import waited with `mysqladmin` and loaded with `mysql` —
+  names the MariaDB 11+ images do not ship (only `mariadb-admin` / `mariadb`; checked in `mariadb:11.4`) — and read the
+  password from two fixed env names, so EVERY `.fab` import of a MariaDB 11+ app timed out and left the app down. The
+  import now loads through the backup side: `appbackup.DiscoverDatabases` (the live container's own credentials) and
+  `appbackup.ImportDump` (mariadb / mariadb-admin; psql `ON_ERROR_STOP` + `--single-transaction`); the import's own
+  `waitForDB` / `importDBDump` are removed. `appbackup.DBTypeForImage` stays the classifier (g). Test
+  `TestR1187_TheImportLoadsTheDumpThroughTheBackupSide` (seams, no Docker), red-proved with the old body.
 - **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