Key the codex session on the instance, not the thread

[vitramir]

Agent state is instance-scoped: an instance serves many threads and they share one conversation. The codex path keyed its session by platform thread, so a reply arriving on a different thread began with no memory of the request that started it.

Seen with a coordinator that polls three agents. Asked on the user's thread, it sent the topic to @ben, @tomas and @viktor — then @ben replied on the poll thread, and the coordinator woke in a conversation that had never seen the topic, the other two profiles, or the thread it owed an answer to. So it went excavating:

agyn threads list
agyn threads show --thread poll-ai-saas-tax-ben     # no such command
agyn threads --help && agyn threads show --help
agyn threads read --thread ... --thread ... --thread ...
find ~ -maxdepth 4 -type f -name '*agyn*'
cat /root/.agyn/threads.json
cat /root/.agyn/codex/thread-mapping/*.json

That is the same bug #161 fixed for agn, whose comment already describes it: "an agent that asked another agent a question could not read the answer in context". The port to codex was never done — 7fc41ee predates it.

Change

ensureCodexThread takes no thread and keys on d.selfID(), matching agn's ThreadID: d.selfID(). The mapping and its store are keyed and named by instance throughout (instance_id on disk), so the names no longer say thread where they mean instance. Which thread a message came from is in its header, as before.

A stale per-thread mapping file is simply never looked up; the instance starts one session and resumes it after a restart, from the same persisted store.

Tests

New: TestEnsureCodexThreadIsOneConversationAcrossThreads — repeated calls return one codex thread, start it exactly once, and store it under the instance. Existing resume/start tests now assert the instance key. Full suite green.