[ENHANCEMENT] Send X-Zoo-Session-ID header to LiteLLM proxy for per-conversation request correlation

[awschmeder]

Problem

When Zoo Code routes requests through a LiteLLM proxy, there is no way for the proxy operator to correlate individual API calls back to a specific Zoo Code conversation thread. LiteLLM natively recognizes the X-<vendor>-Session-ID request header and uses it to tag log entries and spend-tracking records with a session identifier.

Zoo Code already tracks a per-task UUID (taskId) that is unique to each conversation thread and is passed to every createMessage() call via ApiHandlerCreateMessageMetadata. This value is already forwarded to the Zoo Gateway provider as X-Zoo-Task-ID, and to OpenAI Native / Codex providers as session_id. However, the LiteLLMHandler does not forward it at all.

Expected Behavior

When Zoo Code sends a request to a LiteLLM proxy, the HTTP request should include:

X-Zoo-Session-ID: <taskId UUID>

This allows proxy operators to:

• Filter logs by conversation thread
• Track per-session token spend
• Diagnose cache control issues and request timing
• Correlate multi-turn conversations in LiteLLMs dashboard

Current Behavior

The LiteLLMHandler sends no session or task identifier in request headers. The taskId available in metadata is silently dropped.

References

• LiteLLM session tracking docs: https://docs.litellm.ai/docs/proxy/users#tracking-spend-per-session
• Existing X-Zoo-Task-ID implementation in src/api/providers/zoo-gateway.ts
• ApiHandlerCreateMessageMetadata.taskId in src/api/index.ts

Industry Context

This follows the x-<vendor>-session-id convention used by:

• Claude Code: x-claude-code-session-id
• GitHub Copilot: x-copilot-session-id

[awschmeder]

Typical log trace of a ZooCode session in LiteLLM admin console - each LLM call fires a separate line in the log