Follow-up: remove private `ThreadPoolExecutor` internals from clean shutdown path

[griffinmilsap]

Summary

ezmsg currently subclasses concurrent.futures.ThreadPoolExecutor to force daemon worker threads during non-strict shutdown.

This works, but it depends on private CPython executor internals. Python 3.14 changed those internals and broke ezmsg, requiring a compatibility patch.

Why this should be fixed

The current design is fragile because it overrides private stdlib behavior:

• private attributes and worker bootstrap details are not stable across Python releases
• compatibility fixes may be needed again on future Python versions
• parser/runtime behavior can become indirectly coupled to environment-specific dependency breakage

Goal

Remove _DaemonThreadPoolExecutor and stop replacing the event loop's default executor with a subclass that depends on private implementation details.

Preferred direction

Replace the global executor override with targeted daemon-thread handling for the specific blocking operations that must not prevent process exit.

Likely approach:

• introduce a small helper that runs selected blocking callables in daemon threading.Threads
• bridge completion/failure back to the event loop with a future
• use that helper only at shutdown-sensitive call sites

Candidate starting points

• /Users/milsagw1/repos/ezmsg/src/ezmsg/core/backendprocess.py:566
• /Users/milsagw1/repos/ezmsg/src/ezmsg/core/backendprocess.py:850

Acceptance criteria

• no subclass override of private ThreadPoolExecutor internals
• shutdown behavior remains best-effort and does not hang on blocking executor work
• Python 3.14+ works without version-specific executor internals handling
• targeted regression coverage exists for the replacement path