fix: silent memory flush failure on /new and /resume commands

[ryanautomated]

Problem

Sessions reset by /new and /resume never trigger memory extraction. The auto-expiry flush also had this bug (fixed in 9c96f66) but two call sites were missed.

The root cause is a signature mismatch: _async_flush_memories(self, old_session_id: str) accepts one parameter, yet the callers pass two:

```python

gateway/run.py:3247 — /new handler

self._async_flush_memories(old_entry.session_id, session_key)

^^^^^^^^^^^^^^^^^ TypeError

gateway/run.py:4989 — /resume handler

self._async_flush_memories(current_entry.session_id, session_key)

^^^^^^^^^^^^^^^^^ TypeError

```

The TypeError is silently caught at DEBUG level and swallowed, so memory extraction is never attempted.

Why this matters

Users who actively reset sessions with /new (the most common way to start fresh) or switch sessions with /resume get zero memory consolidation. Only automatic idle expiry (which was fixed) actually flushes. This means important conversation outcomes — preferences learned, decisions made, workflows discovered — are lost when the user manually resets.

Fix

Remove the stray session_key argument from both call sites, matching the already-correct expiry loop at line 1312:

File	Line	Change
gateway/run.py	3247	Remove session_key from /new handler
gateway/run.py	4989	Remove session_key from /resume handler
tests/gateway/test_resume_command.py	222	Update test assertion

Impact

• Risk: Near zero. session_key was never consumed inside the flush function — it only uses session_id to load transcripts.
• Test results: 2040 gateway tests pass, 18 flush+resume tests pass, zero regressions.
• Pre-existing failures: 15 unrelated failures (matrix encryption, whatsapp connect, race guards) existed before this change.

Reproduction

Any /new or /resume on any platform (Telegram, Discord, CLI, etc.). The memory_flushed flag on expired sessions never gets set because the flush task crashes before running.