Force the admin password from CM_INITIAL_ADMIN_PASS on every boot

[Robbie1977]

Upstream scripts/docker/create_superuser.py only acts when no superuser exists:

if User.objects.filter(is_superuser=True).count() == 0:
    User.objects.create_superuser(...)

Every VFB instance boots by restoring a *.pgsql dump that already contains
superusers, so that check always fails and CM_INITIAL_ADMIN_PASS is silently
ignored — the admin password is whatever the dump happened to carry. The
passwords have consequently drifted apart (l1em no longer matches the others).

This is a repair, not a new feature. init.sh used to force the password,
but the code could never have worked:

cd /home/django/projectscat /opt/VFB/modify_superuser.py | python manage.py shell &

A missing line break made that cd with two arguments, which fails, and the
&&-chain meant nothing after it ran. It was removed in 40aaeae ("removing
forced password set", 2021) rather than fixed. It also relied on virtualenvwrapper
and a fixed sleep 2m.

Postgres data lives inside the container and only /backup persists, so a manual
correction is wiped on the next recreate. Reapplying on boot is the only durable
fix.

modify_superuser.py now reads CM_INITIAL_ADMIN_USER / CM_INITIAL_ADMIN_PASS
instead of carrying a hardcoded password hash, and is idempotent: it writes only
when the password or the staff/active flags actually differ, and is a no-op when
the variable is unset or the user does not exist.

init.sh invokes it in the background, since catmaid-entry.sh never returns,
polling for up to 10 minutes while the fixture loads and the database comes up.
It uses the current venv at /home/env rather than virtualenvwrapper.

Loaders are unaffected: they start from an empty /backup, so upstream
create_superuser.py already applies the variable correctly there.

Tested against a fixture: retries without hanging when the database never comes
up, applies immediately when ready, recovers when it arrives late, and does not
delay catmaid-entry.sh.