fix(agent): preserve user_id when compression spawns continuation session

[Hewg74]

What does this PR do?

compress_context() in agent/conversation_compression.py spawns a continuation session via agent._session_db.create_session(...) but does not pass user_id. Result: every session created by mid-conversation compression lands with user_id = NULL in state.db, even though the human peer attached to the parent session is unchanged.

This breaks downstream user-scoped queries (Honcho memory provider, peer-attribution logic, any consumer that filters by user_id). Each compression turns a properly-attributed session into an orphan.

The fix is one line: pass agent._user_id through to create_session(). getattr(agent, "_user_id", None) preserves existing behavior for code paths where _user_id was never set (CLI, some test paths) — the default None matches what the old call did implicitly.

Related Issue

Same class of bug as #24333 (which fixes the equivalent site in run_agent.py for bg/cron/delegate sessions). This PR closes the same hole at the compression site. No issue filed; happy to open one if preferred.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• agent/conversation_compression.py:393 — add user_id=getattr(agent, "_user_id", None) to the create_session() call inside compress_context().

How to Test

Reproduction (without the fix):

1. Start a Hermes agent through a platform that sets user_id (Telegram gateway, Slack gateway, etc.).
2. Drive the conversation past the compression threshold so compress_context() fires.
3. Inspect state.db: the parent session has user_id = <expected>, the post-compression continuation session has user_id = NULL.

With the fix: both sessions share the same user_id.

Discovery context: Surfaced while debugging a multi-peer Honcho integration where compressed sessions were silently becoming unattributed even though the Telegram user was unchanged. Tracked to this one line.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(agent): ...)
• I searched for existing PRs (closest is fix(agent): propagate user_id to session-row creation for bg/cron/delegate sessions #24333, different site, same bug class — see Related Issue)
• My PR contains only changes related to this fix (one line)
• I've run pytest tests/ -q and all tests pass — couldn't run full suite from contributor environment; the change is isolated and pattern-matches fix(agent): propagate user_id to session-row creation for bg/cron/delegate sessions #24333. Happy to add a regression test mirroring tests/agent/test_session_user_id.py if maintainers want one.
• I've added tests for my changes — see above; willing to add if requested.
• I've tested on my platform: Ubuntu 24.04 (Hetzner VPS) — running this patch in production for the Sophia Telegram bot since 2026-05-25. No regressions; the NULL-user_id orphan class of sessions stopped occurring.

Documentation & Housekeeping

• N/A — no doc changes
• N/A — no config-key changes
• N/A — no architecture changes
• Cross-platform: pure Python, no platform-specific behavior
• N/A — no tool-schema changes

[Morad37]

Clean fix. The fallback means existing sessions without a attribute (pre-feature sessions) gracefully default to None rather than raising AttributeError, so this doesn't need a migration or a version gate for stored contexts. One less session attribute to lose on compression.

[Morad37]

Minor: the getattr call in the diff uses getattr(agent, "_user_id", None) which bakes in default-None for sessions that don't have that attribute yet. That's the right compat choice -- worth calling out since it means no migration needed.

[teknium1]

Thanks for this — the diagnosis and fix are correct for the rotation path.

Context on why we're closing it: as of #52658 (#38763), compression.in_place now defaults to True. Compaction keeps ONE durable session id for the conversation's whole life — it no longer ends the session and forks a continuation id. Because the session id is unchanged across compaction, the flush cursor / user_id stay attached to the same session — there is no rotation to reset or re-propagate them across.

Rotation now only runs as an explicit opt-out (compression.in_place: false), and the direction is to treat that path as legacy. So this fix hardens a code path that no longer executes by default and that we're not investing further in. Closing as superseded by the in-place default — not a reflection on the code, which was a correct fix for the behavior at the time. Credit preserved in the issue/PR history. Appreciate the contribution.