Anonymous durable MQTT sessions silently persist NO session state: `system.hdb_durable_session` gets 0/20 rows for anony

From dispatch finding (task `qa-wave-2026072116`):

- Anonymous durable MQTT sessions silently persist NO session state: `system.hdb_durable_session` gets 0/20 rows for anonymous clients vs 20/20 for superuser AND 20/20 for an authenticated low-privilege user with zero `system` permissions — so the trigger is a *null user*, not a permission check (same trigger as #1874, different and worse failure mode). No `AccessViolation` appears in the log at all and the client still receives SUBACK with QoS 1 granted, so a `clean:false` anon subscriber believes it holds a durable session and has none. Proved over 4 consecutive runs, 20-rep churn per arm, read before any disconnect so #1874's leak cannot contaminate it; the exact internal short-circuit line is NOT pinned (honest gap — a deliberate "no durable session without identity" guard is a live alternative reading, though anon *does* successfully write its `hdb_session_will` row per #1874, which argues against by-design).

Reproduce the four-run churn comparison for anonymous, superuser, and authenticated low-privilege clients, then inspect rows in system.hdb_durable_session before disconnect and compare the hdb_session_will behavior described in #1874. Trace the durable-session path to identify the null-user short circuit or confirm an intentional identity guard; done requires a documented decision and tests covering anonymous clean:false sessions.

Written by the indexing model from the issue text.