stop the gate demanding what a session cannot do

[ayushcodes10]

An eigen session reported "Ran 5 stop hooks" and spent 27 minutes unable to satisfy any of them. Three separate faults, all mine, all in #33.

1. stop_hook_active never bounded anything

I claimed "fires once per session" and shipped it as a headline safety property. The flag is set only while a session is continuing from a stop hook — once the agent answers and stops again, it is a fresh stop with the flag clear. The bound was never enforced.

Gated sessions are now recorded in stop_gate_fired (migration 0010) and never gated twice, whatever the flag says. Inferred bounds don't hold; recorded ones do.

2. The command it printed could not run

The reason said:

echo-memory pending --done <paths>

echo-memory is not on PATH for a virtualenv install. So the one route that did not need the MCP tool did not work either — the session was told to run something that returns command not found.

It now prints the hook's own ECHO_MEMORY_BIN, falling back to the bare name only when argv[0] is not this CLI (imported under pytest, argv[0] is the pytest binary — caught by an existing test).

3. There was no way out

The gate cannot see the session's tool list, and that session had no write_episode in it. Blocking achieved nothing and cost real time.

The reason now tells a session that can reach neither the tool nor the CLI to say so in one line and stop, and states plainly that the gate will not fire again for it and the files stay queued for a session that can. An unsatisfiable demand with no stated exit is worse than no gate at all.

Testing

• 401 pass, 6 added — including one that fires the gate twice for the same session id and asserts silence the second time
• migration 0010 verified to apply and reverse standalone
• the pytest-argv[0] fallback is pinned by its own test