MQTTManager: stop a room's status thread when the room is destroyed

[jamesmulcahy]

Problem

Each Room starts a detached thread that waits on the room's own mutex and condition variable, and sends the room's status, forever. Nothing stops it.

When a room is deleted, EntityManager drops the Room, but its thread keeps running against the freed object. What happens next depends on what the thread was doing:

• Waiting for the next change: it stays blocked on a freed condition variable. It can wake later, once that memory is reused for something else.
• Waiting for a change to settle (about 100 ms by default): it goes on to build and publish a status from freed memory.

That can crash the manager at an unrelated point. It can also publish a stale state to the deleted room's topic, just after ~Room() cleared it.

The test suite already worked around this. create_room() warned that rooms can't be safely destroyed.

Fix

• The status thread is now a std::jthread. Both of its waits take its stop token.
• ~Room() stops and joins the thread before anything else is torn down. Stopping wakes the thread from either wait, so the join only waits for an update that's already being sent.
• Debounce: it used to detect "another change arrived" from wait_for() returning no_timeout. The stop-token overloads take a predicate instead, so changes are now counted, and the wait continues while the count keeps changing. The debounce behaves the same, except that a spurious wakeup no longer restarts it.
• EntityManager::load_rooms() destroys removed rooms after releasing _rooms_mutex. That way the join can never wait while holding that lock.
• Self-join guard: if a room were ever destroyed on its own thread (nothing does this today), ~Room() logs an error and detaches instead of throwing from join().

Tests

tests/room_test.cpp covers three cases:

• A burst of changes produces exactly one status publish, which checks the reworked debounce.
• Destroying a room while it's waiting for a change to settle stops its thread: nothing is published afterwards, and destruction doesn't hang.
• A room removed from the database is unloaded and destroyed by load_rooms().

Notes

• The test binary still ends with std::_Exit(). Room threads were one reason for it, but static destruction order across translation units and other unstopped threads (weather, OpenHAB light group events) remain. I've updated the comment to say so.
• The logger race fixed in MQTTManager: don't let new messages overtake ones buffered while disconnected #403 (Room threads logging while ScopedErrorLog changes the logger's sinks) can still hit this branch's CI until MQTTManager: don't let new messages overtake ones buffered while disconnected #403 merges.
• Separate follow-up: a config reload runs inside the SIGUSR1 signal handler, which can interrupt any thread, including a room's own.

🤖 Generated with Claude Code