fix(honcho): respect writeFrequency in sync_turn

[starship-s]

Context

Honcho's writeFrequency setting is the user's control for when completed conversation turns are written to Honcho: immediately, asynchronously, at session end, or every N turns. This matters for users who intentionally defer or batch writes, especially for session-end or cadence-based memory syncing.

The sync_turn() path was appending the turn and then calling _flush_session() directly. That bypassed HonchoSessionManager.save(), which is where writeFrequency routing is applied. As a result, deferred modes such as session and integer cadences could silently behave like per-turn writes.

Change

• Route Honcho sync_turn() persistence through HonchoSessionManager.save() so configured writeFrequency modes are honored.
• Add regression coverage for async, turn, session, and integer write-frequency routing from sync_turn().

Why this approach

HonchoSessionManager.save() already centralizes the write-frequency decision. Routing sync_turn() through it keeps the completed-turn sync path consistent with the rest of the Honcho session manager, while preserving immediate flushing for modes that are supposed to flush immediately.

This keeps the fix narrow: one routing change plus tests for each supported write-frequency mode.

Test Plan

• python -m pytest tests/honcho_plugin/test_sync_turn_write_frequency.py tests/honcho_plugin/test_async_memory.py -q (45 passed)
• python -m pytest tests/honcho_plugin -q (271 passed)

[teknium1]

Thanks for the focused regression fix. The premise remains valid on current main: HonchoMemoryProvider.sync_turn() calls _flush_session() directly at plugins/memory/honcho/__init__.py:1239, while HonchoSessionManager.save() is the existing routing boundary for async, turn, session, and integer cadence modes at plugins/memory/honcho/session.py:500-522. The provider already calls flush_all() at session end (plugins/memory/honcho/__init__.py:1283-1295), so the proposed route preserves the deferred-session contract.

Automated hermes-sweeper review.

[yw0nam]

Reproduced this on current main in a live Hermes+Honcho setup: a profile with writeFrequency: 20 had effective config correctly resolved to 20, but every completed turn still reached Honcho because HonchoMemoryProvider.sync_turn() directly invoked _flush_session() instead of the manager routing boundary.

I verified the minimal routing change (manager.save(session)) with the existing ingest regression plus test_async_memory.py: 43 passed. The broader tests/honcho_plugin run reached 419 passed; its 4 failures are unrelated cache-busting tests that reuse HERMES_HOME in-process.

This directly addresses the observed every-turn persistence and keeps the existing on_session_end() → flush_all() partial-batch behavior intact.