New 'tether' protocol threads API requests across turns (off by default)

What

• A new subsystem decides, per assistant turn, whether an API request should continue a previous server-side "thread" (previous_message_id) or start a new one. It tracks per-agent thread state, retries on thread-related errors (thread_not_found, thread_fingerprint_mismatch, thread_already_continued), and falls back to stateless mode when the server rejects thread continuation. This feature is gated and off by default.
• Three new telemetry events were added for it: one fired when deciding to create/continue a thread, one on the final outcome of the live request, and one ("echo audit") auditing divergence between sent and echoed conversation turns.
• The echo-audit piece compares the message content sent versus what the server echoed back, classifying differences such as reordered, turn_split, turn_dropped, added/dropped tool_use, tool_name_changed, or caller_dropped, and reports them via tengu_tether_echo_audit.

Why Threading requests server-side can reduce redundant context sent per turn, but only works if server and client stay in sync; the echo-audit and outcome telemetry let this be verified and the retry/fallback logic keeps conversations working even when the server rejects or loses a thread.