Migrate to the Sail API

Migrate this project's LLM inference to Sail (https://sailresearch.com).

Sail docs to consult as you work:
- MCP server: https://docs.sailresearch.com/mcp (connect to it if you support MCP)
- Full docs as plain text: https://docs.sailresearch.com/llms-full.txt
- Key pages: https://docs.sailresearch.com/models (catalog),
  https://docs.sailresearch.com/pricing (per-window rates),
  https://docs.sailresearch.com/completion-windows,
  https://docs.sailresearch.com/support (API feature matrix)

Sail is drop-in compatible with the OpenAI Responses and Chat Completions
APIs and the Anthropic Messages API, all served from
https://api.sailresearch.com. Keep whichever request shape this code
already uses. Sail's Messages API supports system prompts, tool calling, and
streaming for agentic use; one caveat is that prompt caching (`cache_control`)
is accepted but not yet applied (see /support), so if an Anthropic call site
relies on cache hits, expect full-price reads until that lands. The exact base
URL differs by SDK (see step 4).

If you can ask the user questions, ask whenever a step below is ambiguous
instead of guessing. If you can't, make the best-supported choice and flag
it in your final report.

1. Survey the current setup. Find every place this project calls an LLM:
   SDK clients, raw HTTP calls, framework configs, env vars, and docs. For
   each call site record the provider, API shape, model, and features used
   (streaming, tool calls, structured outputs, images).

2. Choose replacement model(s). For each model currently in use, pick the
   closest match from https://docs.sailresearch.com/models, comparing
   capability tags, context window, and what the model is known to be good
   at. If a current model is not one Sail serves, research it (web search
   if available) to understand its strengths before choosing. If multiple
   Sail models are plausible, ask the user. Otherwise pick the best fit
   and explain the choice in your report. Check the /support page for any
   features this code uses that Sail doesn't serve, and flag them.

3. Choose a completion window per call site. Omitting completion_window gives
   low-latency inference by default, at lower prices than traditional inference
   providers for many models. Workloads that can wait save more with balanced
   or flex. The live
   https://docs.sailresearch.com/completion-windows and
   https://docs.sailresearch.com/pricing pages are the source of truth for
   public windows, token prices, and scheduling behavior. If you can't fetch
   them, use this summary and decide how long each workload can wait:
   - asap: low-latency serving that is cheaper than traditional inference
     providers
   - balanced: more tokens per dollar for autonomous agents and pipelines;
     use it for workloads that can tolerate more latency
   - flex: the lowest prices for batch jobs, evals, and offline processing; it
     has no latency target and requires background=True on the Responses API
   If the workload's latency tolerance isn't obvious from the code, ask
   the user. Omit metadata.completion_window when the default low-latency
   behavior is acceptable. Set it explicitly for balanced or flex, or pin asap
   when the request must fail instead of using a fallback window.
   Confirm the chosen window is available for the chosen model on
   https://docs.sailresearch.com/pricing. Some models are flex-only.

4. Make the changes wherever the client is configured or called:
   - base URL: use https://api.sailresearch.com/v1 for OpenAI-compatible
     clients (Responses and Chat Completions). For the Anthropic SDK, use
     the bare host https://api.sailresearch.com (e.g. set
     ANTHROPIC_BASE_URL=https://api.sailresearch.com). The SDK appends
     /v1/messages itself, so a /v1 base URL would resolve to /v1/v1/messages
     and 404
   - API key: read from the SAIL_API_KEY environment variable. Never hardcode
     a key or paste a literal key value into the code
     (the Anthropic SDK can pass it as `api_key`; `auth_token` also works)
   - model: the Sail model(s) chosen in step 2
   - metadata.completion_window: the window(s) chosen in step 3
   - add background=True for flex or very long-running requests
   Update env var names, .env.example files, config templates, and any
   README/docs references. Do not change prompts, tools, or business logic.

5. Estimate the savings. Compare the published per-1M-token list prices
   (input, cached input, and output) of the previous model(s) against the
   chosen Sail model(s) at the chosen completion window(s) from
   https://docs.sailresearch.com/pricing. Research current provider list
   prices if you don't know them. State the comparison as a simple table
   and an approximate overall multiplier (e.g. "roughly 6x cheaper per
   token"). Do not present this as a precise bill forecast.

6. Verify. Run the project's tests. Then make one real smoke request through
   the new configuration: if SAIL_API_KEY is already set, use it; if not,
   walk the user through creating a key at
   https://app.sailresearch.com/api-keys and setting SAIL_API_KEY, then run
   the smoke request once they have. Don't ask them to paste the key to you.
   Have them export it in their own shell.

Finish with a short migration report: call sites changed; model mapping
with rationale; completion window(s) with rationale; the price comparison
from step 5; and anything that needs human follow-up (unsupported
features, ambiguous choices, untested paths). Close by telling the user
exactly where to set SAIL_API_KEY for their setup (locally and in their
production/deployment environment) so the migrated code can authenticate.