2.5 follow-up — which password signs in after remove-keeping-backups + restore (9202, 2026-10-10)
The fixture reported that the install's password stopped working. That is true and expected:
a `type: password` field is not in PortableSecretEnvVars, so it does not travel in the backup
unit and the box mints a new one. The question is whether the value the box now holds — the
value its page shows the household — signs in, and whether the DATA came back.

the container's own environment, names only:
  
  APP_UID=<value>
  ASPNETCORE_HTTP_PORTS=<value>
  ASPNET_VERSION=<value>
  DOTNET_RUNNING_IN_CONTAINER=<value>
  DOTNET_VERSION=<value>
  LUBELOGGER_LOCALE_OVERRIDE=<value>
  PATH=<value>
  ROOT_PASSWORD=<value>
  ROOT_USER=<value>
  TZ=<value>

what the app answers a stranger right now:
  GET /api/vehicles with no credentials -> 401

the password the INSTALL generated (the one the fixture holds), 30 characters:
  {"success":false,"message":"Invalid Login Credentials"}
the password the BOX HOLDS NOW, read from the app's own deployed environment:
  it is 24 characters, and the name is 'csalad'
  a DIFFERENT value from the one the install generated
  {"success":true,"message":""}
and the data the household had before the remove:
  [{"id":1,"imageLocation":"/defaults/noimage.png","mapLocation":null,"year":2019,"make":"Skoda","model":"Octavia","licensePlate":"FEL-EBA5E5","purchaseDate":null,"soldDate":null,"purchasePrice":0,"soldPrice":0,"isElectric":false,"isDiesel":true,"useHours":false,"odometerOptional":false,"extraFields":
