v0.87.1 — carry existing operators across

An operator carried across from before the subject unification could no longer sign in.

0.87.0 left the attaching to verifyPassword(): the local hash stayed the credential and the subject was created on that operator's next successful sign-in — the only moment the plaintext is available to seed one. That is correct while a sign-in exists which verifies against the local hash.

It stops being correct the moment a host makes operator authority a permission on the ordinary sign-in and retires the separate operator login form — which is what 0.87.0 exists to enable. That form was the only caller reaching the bootstrap window. On an upgraded deployment every existing operator then has no subject, no account to sign in as, and no door that consults their hash: locked out of the platform they run, by an upgrade that reports success.

A migration now attaches a subject to every operator that lacks one. The plaintext is gone but the hash is not, and it needs no re-deriving — both tables hash with the configured driver and both models pass an already-hashed value through untouched — so the credential moves and the password keeps working.

An operator who is also an account member is pointed at the subject they already have rather than given a second one, and their live password is left alone. The address is not marked verified: nothing here proves control of it.

A migration rather than a command, deliberately. A command is a step someone has to know about, and the failure mode for not knowing is that nobody can administer the platform — discovered after the deploy, by the person who can no longer fix it.