MQTT password-change does not invalidate HTTP sessions

[fabracht]

Context

PR #68 closes the HTTP scope of #37: POST /auth/password/change and POST /auth/password/reset/submit now destroy other HTTP sessions for the same canonical_id and revoke their JTIs.

The MQTT password-change path ($DB/_auth/password/change, handled by handle_password_change_mqtt in crates/mqdb-agent/src/agent/handlers.rs:1109) is intentionally out of scope and remains affected by the original flaw: it updates _credentials and returns success without touching SessionStore or JtiRevocationStore.

Why it's not in PR #68

AdminContext (crates/mqdb-agent/src/agent/handlers.rs:267-280) holds no reference to SessionStore or JtiRevocationStore. Threading them through is plumbing that touches the MQTT admin dispatch surface and belongs in its own change.

Scope

• Add session_store: Option<&'a Arc<SessionStore>> and jti_revocation: Option<&'a Arc<JtiRevocationStore>> to AdminContext (Option-wrapped because cluster-agent mode may not run an HTTP server).
• In handle_password_change_mqtt, after the successful update_entity_db, call destroy_others_by_canonical_id(canonical_id, None) (no current HTTP session at MQTT request time) and revoke the returned JWTs' JTIs.
• Same for handle_password_reset_submit_mqtt (crates/mqdb-agent/src/agent/handlers.rs:1367).
• Wire the stores in at the AdminContext construction site (crates/mqdb-agent/src/agent/handlers.rs:80).
• Add integration tests covering MQTT password change with one active HTTP session — verify the session is destroyed and the JTI is revoked.

References

• Original issue: invalidate other sessions on password change #37
• Partial fix (HTTP scope): invalidate other sessions on password change #68