fix: prevent stale lock-skip signal leaking between compress_context calls

Advisor review found a critical stale-signal leak: if auto-compress
sets _compression_skipped_due_to_lock during a lock-skip, a subsequent
successful manual /compress will see the stale signal, falsely report
'Compression already in progress', and discard the compression results.

Fix:
- compress_context clears _compression_skipped_due_to_lock = None at
  entry so each call's outcome alone determines the signal.
- Unified gateway 'holder: unknown' drift to match CLI/TUI pattern
  (omit holder clause when not a descriptive string).
- Added MagicMock opt-outs in 3 sibling test files broken by the new
  signal check (test_compress_here, test_compress_focus,
  test_compress_plugin_engine).
- Added stale-signal-leak invariant test proving the fix.

tests/cli/test_compress_here.py

@@ -26,6 +26,7 @@ def _wire_agent(shell, compressed_head):
     shell.agent.session_id = None
     shell.agent.tools = None
     shell.agent._compress_context.return_value = (compressed_head, "")
+    shell.agent._compression_skipped_due_to_lock = False
 
 
 def test_compress_here_compresses_head_only(capsys):