Summary

Closes #29507. P1 — TLS application-data bytes were being written on top of unrelated file descriptors (in production: kanban.db's SQLite header), causing silent persistent-state corruption and data loss on recovery.

Root cause

The reporter's forensic is conclusive — the 24 bytes that overwrote bytes 5..28 of kanban.db are exactly the shape of a TLS 1.2 application-data record (5-byte header 17 03 03 00 13 + 19-byte encrypted payload). The only producer of that byte pattern in the process was the OpenAI/httpx TLS stream from the interrupted Codex request.

Mechanism:

1. Worker thread (Thread-1616, the _call thread inside interruptible_api_call) creates an OpenAI client, gets a TCP socket with FD X, hands it down through httpx → httpcore → ssl → OpenSSL BIO. The BIO caches X as a raw integer.
2. The user interrupts. The interrupt-check loop runs on asyncio_0 (a stranger thread w.r.t. the worker) and calls _close_request_client_once(\"interrupt_abort\"). That walks force_close_tcp_sockets (shutdown + close) and then client.close() (which again closes pool sockets).
3. socket.close() releases the integer FD to the kernel.
4. The next open(2) in the same process — the kanban dispatcher opening kanban.db — gets FD X.
5. The worker eventually unblocks (its blocked recv returns), httpx flushes one last TLS application-data record via the still-live BIO, which calls write(X, …). The bytes land in kanban.db because the kernel reassigned X.

This is FD aliasing across threads: the SSL layer's BIO caches the FD as an integer, so once a stranger thread releases that integer to the kernel, anything else opening a new FD wins the race against the worker's pending TLS flush.

Fix (two prongs, both required)

Prong 1 — force_close_tcp_sockets is shutdown-only

shutdown(SHUT_RDWR) from any thread is FD-safe — it sends FIN, breaks pending recv/send, but does NOT release the FD integer. The owning httpx worker's natural unwind closes the underlying socket.socket via the same Python object, which atomically swaps _fd → -1 before issuing close(2) — so the FD release happens from exactly one thread that nobody else races.

Prong 2 — _close_request_client_once is thread-aware

Even with prong 1, the followup client.close() in _close_openai_client walks the httpx pool and closes sockets from whatever thread invoked it. We stamp the per-request client holder with the owning thread ident at _set_request_client time and:

• Owning thread (the worker's finally) → pop holder + full client.close() as before.
• Stranger thread (interrupt loop, stale detector) → new _abort_request_openai_client: shutdown sockets only, log deferred_close=stranger_thread, do not touch the holder. The worker's finally later sees the client still there and closes it from its own thread context — where FD release races nothing.

Applied symmetrically to both the non-streaming interruptible_api_call and the streaming variant.

Prong 3 (defense-in-depth) — already exists

hermes_cli.kanban_db._validate_sqlite_header already detects this exact TLS-shaped corruption at open time and refuses to operate on the file (that's the kanban dispatcher: ... is not a valid SQLite database line in the reporter's log). Kept intact — it's the reactive layer; this PR is the proactive layer that stops the bytes from being written in the first place.

Why three commits?

• Commit 1 — Prong 1: the minimal surgical change in force_close_tcp_sockets (drop sock.close(), shutdown only) with a long docstring naming the failure mode by issue number.
• Commit 2 — Prong 2: owner-thread tracking in both interruptible_api_call variants, plus the new _abort_request_openai_client agent method that does shutdown-only with a distinguishable log line.
• Commit 3 — Tests: 10 regressions in a dedicated tests/run_agent/test_tls_fd_recycle_corruption.py, plus the existing test_force_close_tcp_sockets_descends_httpcore_1_connection_wrapper updated to assert close_calls == 0 (was 1).

Test plan

• pytest tests/run_agent/test_tls_fd_recycle_corruption.py → 10 new tests pass.
• pytest tests/run_agent/test_streaming.py tests/run_agent/test_stream_interrupt_retry.py tests/run_agent/test_create_openai_client_reuse.py tests/run_agent/test_primary_runtime_restore.py tests/hermes_cli/test_kanban_db.py → 247 existing tests still pass.
• Linter clean.
• Reviewer: in production, after deploying, look for the new OpenAI client aborted (... deferred_close=stranger_thread) log lines on /stop-interrupt scenarios — the absence of subsequent kanban dispatcher: ... is not a valid SQLite database errors confirms the race is closed.

Observability changes (heads-up for dashboards)

The interrupt-abort path now emits OpenAI client aborted (..., tcp_force_closed=N, deferred_close=stranger_thread) instead of OpenAI client closed (..., tcp_force_closed=N). The tcp_force_closed=N field shape is preserved so existing parsers keep working; the new deferred_close=stranger_thread marker is purely additive.