fix(accounts): first-login password change is stored, not in the session

The forced change of the generated admin password was a session flag
set at login when the password still matched data/admin_password. A
new session after the file was gone bypassed it.

- UserAttributes.must_change_password (migration 0007) holds it; the
  admin created with a generated password gets it, and a password
  change clears it. ForcePasswordChangeMiddleware reads it.
- A system check (accounts.E001) stops the server unless the middleware
  follows AuthenticationMiddleware; the README has the settings change.
- If the generated password cannot be stored privately, provisioning
  stops without printing it and without creating the admin (one
  transaction for the user and its attributes).
- The admin is provisioned on any real migrate run while no user
  exists, so running migrate again after a failure creates it; flush
  (plan=None) and rollbacks of accounts are skipped.
- The post_migrate receivers check the migration state for the models
  they use, so a targeted migrate on a fresh database (e.g. migrate
  appsettings) no longer fails with 'no such table'.

README.md

@@ -394,6 +394,19 @@ environment=CSRF_TRUSTED_ORIGINS="https://webvirtcloud.example.com"
 
 ## How To Update
 
+Before running migrations, add `accounts.middleware.ForcePasswordChangeMiddleware`
+to `MIDDLEWARE` in your existing `webvirtcloud/settings.py`, after
+`django.contrib.auth.middleware.AuthenticationMiddleware` (and the OTP/login-required
+middleware, if present). A system check rejects a missing or misplaced middleware.
+The template is not copied over an existing settings file during an upgrade.
+
+Migration `accounts.0007` transfers the first-login requirement from any existing
+`data/admin_password` file to the user record. Run migrations as a user who can read
+that file. Thereafter, deleting or losing access to the file does not bypass the
+requirement. If provisioning cannot write a new private password file, it stops
+without creating an admin account or printing its password; fix the directory
+permissions and rerun migrations.
+
 ```bash
 # Go to Installation Directory
 cd /srv/webvirtcloud
@@ -412,7 +425,10 @@ sudo systemctl restart supervisor    # supervisord on RHEL / openSUSE
 
 ## Running Tests
 
-WebVirtCloud includes unit tests for both Django models/views and the `vrtManager` libvirt abstraction layer. The test suite uses isolated mock drivers by default and does not require a live KVM hypervisor.
+WebVirtCloud includes unit tests for both Django models/views and the `vrtManager` libvirt abstraction layer. The suite includes mocked regression tests and disk/clone tests using libvirt's
+in-process `test:///default` driver. The live compute and instance integration
+tests still require a configured libvirt host and are skipped when it is unavailable;
+a green result with skips does not establish live KVM compatibility.
 
 ### 1. Setup Virtual Environment
 Use the same virtualenv as in [Local Development Setup](#local-development-setup), steps 1–3. Tests need the secret key too.