Persist TS3 identity across container restarts

[queueeee]

Summary

Every container start was minting a fresh hashcash-mined TS3 identity, so the TS6 server saw each restart as an unrelated cryptographic client. Stream slots from previous runs accumulated as zombies that the TS6 client UI still listed for joins; clicking a zombie routed the request to a long-gone clid and the live bot saw nothing.

This matches the symptom we just hit in network_mode: host: TS3 heartbeats flowed every second, the bot held a fresh setupstream slot, but notifyjoinstreamrequest never showed up in the log when a viewer clicked Join. The click was hitting one of the older zombie slots from previous OOM/revert restarts in this debug session, not the live one.

Changes

• New src/ts6_stream_bot/ts3lib/identity_store.py with load_or_generate_identity(path, security_level) — atomic write via tempfile + os.replace, file mode 0600, parent dir created on demand.
• Loader validates the stored public-key string against the private scalar (catches a tampered or truncated file before any signing happens). Corrupt JSON or invalid pairs fall back to fresh generation rather than locking the bot out.
• controller._connect_ts6 swaps the unconditional generate_identity_async for the new helper.
• config.py: IDENTITY_PATH (default /app/state/identity.json) and IDENTITY_SECURITY_LEVEL (default 8).
• docker-compose.yml: new bot-state named volume mounted at /app/state. Existing operator setups need a one-time docker compose ... up -d to create it; data layer is otherwise unchanged.
• .env.example: documents the two new keys.

Operator notes

After merging, on the live host:

cd /opt/ts6-stream-bot
docker compose -f docker-compose.yml -f docker-compose.host.yml down
docker compose -f docker-compose.yml -f docker-compose.host.yml up -d --build
docker compose -f docker-compose.yml -f docker-compose.host.yml logs -f

First start mines + writes a new identity (the hashcash work happens once). Every subsequent restart reuses the same identity, so the TS6 server cleans up the previous session via its normal client-disconnect path and there is exactly one stream slot per bot in the channel UI.

The bot-state volume holds the bot's TS6 credentials — anyone with read access to the host-side path can impersonate it, so treat that directory as sensitive.

Test plan

• pytest — 228 passed, 1 skipped (full suite, including 9 new identity_store tests covering cold start, warm start, corrupt JSON, invalid keypair, file permissions, missing parent dir, tempfile cleanup, and concurrent first-call race).
• mypy --strict clean (37 source files).
• ruff check clean.
• Live test on the host: docker compose ... down && up -d --build, click Join in TS6 client → expect ts3.command_received command=notifyjoinstreamrequest followed by stream_publisher.viewer_offer_sent in the bot log.

https://claude.ai/code/session_016DuCjRJK995Tj9aDhhB9at

---

Generated by Claude Code