Bug Description

Hermes could print a valid response and then abort during interpreter teardown in Honcho-enabled CLI runs. This was easiest to reproduce in short-lived one-shot commands like hermes chat -q ....

Root Cause

Hermes's Honcho integration started several daemon background threads for context prefetch, dialectic prefetch, sync, and async writes. During process shutdown, some of those workers could still be doing HTTP/SSL work while Python was already in Py_FinalizeEx, leading to an abort after the response had already been returned.

Fix

• track Honcho manager-owned background workers and join them during shutdown
• track provider-owned Honcho workers and stop accepting new background work once shutdown begins
• route provider shutdown through HonchoSessionManager.shutdown() instead of only flush_all()
• add regression coverage for manager/provider shutdown behavior

How to Verify

1. Run ./venv/bin/python -m hermes_cli.main -p 273 chat -q "Reply with exactly OK" repeatedly in a Honcho-enabled profile.
2. Confirm the command returns RC:0 after printing the response instead of intermittently aborting with a coredump.
3. Run the targeted Honcho tests below.

Test Plan

• Added regression test for this bug
• Existing tests still pass
• Manual verification of the fix

Commands run:

• ./venv/bin/python -m pytest tests/honcho_plugin/test_async_memory.py tests/honcho_plugin/test_session.py -q
• ./venv/bin/python -m py_compile plugins/memory/honcho/session.py plugins/memory/honcho/__init__.py tests/honcho_plugin/test_async_memory.py
• repeated manual one-shot CLI smoke tests on profile 273

Risk Assessment

Medium — this changes Honcho shutdown/lifecycle behavior, but the blast radius is limited to Hermes's Honcho integration and is covered by targeted regression tests.