feat(users): unlock and start unencrypted users at boot

A login is what makes an *encrypted* database readable; for an
unencrypted one it gated nothing but the runtime — the file has no key
and is already readable by this process. The cost was user-visible and
read as a bug: after every restart the Telegram bot answered "your
account is locked, log in via the web app", cron fired nothing and no
background agent ran, until a human opened the SPA.

`Skald::new` now calls `UserManager::unlock_all_unencrypted`, which
registers the pools exactly as a login would and refuses an encrypted or
inactive user. Unlocking alone only makes the data readable, so
`wiring::spawn_unlocked_user_runtimes` then builds a `UserContext` for
each — cron, the notify queue, the hub and the per-user MCP runtime all
hang off it. That build is a background supervisor task rather than part
of `new()`: it starts every member's MCP servers inside their container,
and the HTTP listener must not wait behind it. The same two steps run
per user off the lifecycle bus (`UserCreated`,
`UserActiveChanged{active:true}`, after the container `ensure`), so a
member created at runtime does not wait for the next restart.

Two boundaries stay where they were. Authentication is untouched:
`SessionStore` sits above `UserManager`, so no HTTP request
authenticates as anyone because of this. And the auto-unlock is
deliberately not on a lazy path such as `Skald::user_context` —
`revoke_user_runtime` locks a pool synchronously and expects nothing to
re-open it, so the writers of that map stay boot, login and the bus.

`open_db` and the two unencrypted openers now share `register_unlocked`
and `open_unencrypted_file`; `open_unencrypted` (the supervision path)
still does not register its pool.

crates/plugin-mobile-connector/src/lib.rs

@@ -169,9 +169,9 @@ impl MobileConnectorPlugin {
         }
 
         // Reconcile loop: (re)spawns forwarders for bound users as they unlock. Its
-        // first tick fires immediately (covering already-unlocked users at start),
-        // then it periodically catches users who log in later — there is no "user
-        // unlocked" event to hook, and at boot every pool is locked (§9).
+        // first tick fires immediately (covering the unencrypted users, unlocked at
+        // boot), then it periodically catches encrypted ones as they log in — there
+        // is no "user unlocked" event to hook (§9).
         {
             let app4 = Arc::clone(&app);
             handles.push(tokio::spawn(events::reconcile_loop(app4)));