Require aiosqlite 0.22.1 - #1898

• There's no public way to wait for the thread. Add a join() method omnilib/aiosqlite#387 has had no response since July, and nothing has landed upstream since 0.22.1 (Dec 2025).
• Awaiting the future that stop() returns doesn't help either. close() already awaits the one from its own stop() call, and the worker schedules its result just before leaving its loop. Calling stop() again afterwards returns a new future that never resolves, because the worker is gone.
• The join is still needed. Without extra load the thread is rarely still alive when close() returns: 0 of 600 cycles in one run, 2 of 600 in another on a busy machine. With two CPU-bound threads competing for the GIL and a short switch interval, it was still alive in 10 to 15 of 200.
• SQLAlchemy reaches into connection._thread for 0.22 too (SqlAlchemy aiosqlite wrapper doesn't close the aiosqlite connection object (hanging thread) sqlalchemy/sqlalchemy#13039, to make it a daemon thread). zzzeek wasn't happy about it either, but merged it.
• If aiosqlite ever renames it, the failure is mild: the AttributeError comes after the connection is already closed, ControllerApplication.shutdown() logs it as a warning, and our shutdown tests that use _thread fail in CI once it rebuilds its environment, so we'd notice.

On the SQLAlchemy port (#1637, closed as stale): SQLAlchemy still runs on aiosqlite underneath. Its dialect closes connections with a plain await connection.close() and no join, and since 0.22 it avoids hangs at exit by setting connection._thread.daemon = True. So a port moves the private access into SQLAlchemy rather than removing it; the window after close() stays, but the process can still exit because the thread is a daemon. On the ordering question: I don't think the port has to come first. The storage-seam work for the generic store needs a key/value interface routed through the worker, a migration strategy, and lifetimes that don't hang off foreign keys. SQLAlchemy doesn't provide any of those by itself. Where it would help is as a statement builder, or if we want other backends later. If we do port, two things have to be redone: the #1835 commit batching (the timer and forced commits drive commit() on the aiosqlite connection), and the migration rollback that #1637's description says fails. Either way, this PR is small and independent of that decision, and it unblocks 0.22 now.

• HA runtime: runner.py replaces threading._shutdown with deadlock_safe_shutdown() (homeassistant/util/thread.py). That collects threads that are alive and not daemon, joins them within a shared 10 s budget, and only logs if join() itself raises. A daemon thread is skipped; a non-daemon one that is still finishing just gets joined. Neither logs anything.
• HA's and zha's test suites: their verify_cleanup fixtures fail on any new thread after a test except _DummyThread and waitpid threads (and, in HA, _run_safe_shutdown_loop), so the daemon flag wouldn't exempt anything there. Neither suite opens a zigpy database, though: both set CONF_DATABASE: None for the app controller, so no aiosqlite thread is ever started in them.
• Python itself (aiosqlite 0.22.1, Python 3.14): an unclosed connection only lets the process exit if it gets garbage-collected first, because aiosqlite's __del__ then stops the thread. If something still holds a reference at exit, as SQLAlchemy's pool does, plain Python waits on the non-daemon worker thread forever. With _thread.daemon = True set before the connection is awaited, it exits, with aiosqlite's ResourceWarning. Under HA, deadlock_safe_shutdown() would cap that wait at 10 s.
• What SQLAlchemy's flag does: it keeps an open (or still-finishing) worker thread from holding up interpreter exit. It doesn't make the thread finish any sooner after close(). It is also only set when the dialect calls aiosqlite.connect() itself, not when an async_creator_fn is passed.