USR369 directed fixing the DLM timeout directly rather than waiting on cross-lane escalation. Wrote a temporary diagnostic PHP script (not in protected systems/commands/, no whitelist issue) that connected to the live gym.db directly and timed the real query for profile=DLM: connect 0.3ms, COUNT 0.7ms for 19 rows, full SELECT 0.3ms for 26,666 bytes, journal_mode=wal with 0-byte wal file (no lock contention). Compared against profile=david (16 rows, similar timing) - no meaningful difference. Conclusion: the database read itself is instant, there is no server-side data/query hang to fix. Retracted the earlier Server[40] escalation (inbox 870) with a correction (inbox 871) explaining the finding and that no action is needed on their end. Likely explanation for the original note: either the pre-K-GYM-03 double-? URL bug (fast error, not a slow timeout - imperfect fit) or an egress-proxy blip on a testing session (matches platform K215/K216 pattern). Diagnostic script neutralized to a 404 stub immediately after use (no delete API exists, T741).