Improve API protocol setup for custom providers

[johnnygreco]

Overview

When users add a custom OpenAI-compatible provider, Tau currently gives them no
way to choose between Chat Completions and the Responses API. This PR adds that
choice to both custom-provider setup flows and uses it consistently when sending
requests.

Users can select the API through tau setup or /login custom. Tau stores the
selection alongside the existing provider metadata and uses it regardless of how
the model is named. The routing follows Pi's resolved-model API behavior, where
provider and model metadata determine which transport is used.

User experience

The CLI accepts an --api option during setup.

tau --provider company-ai \
  --model company/openai/gpt-5.6 \
  --api openai-responses \
  setup

The /login custom flow presents the same choice with friendly labels.

• OpenAI Chat Completions
• OpenAI Responses

The selector defaults to Chat Completions and supports keyboard-only navigation,
including accepting the default selection with Enter.

The supported configuration values are

• openai-completions
• openai-responses

Tau stores the selection alongside the existing provider metadata in
~/.tau/catalog.toml. Individual models can override the provider-level choice
through model metadata. Provider preferences remain in providers.json, and
session JSONL remains unchanged.

Protocol resolution

Tau resolves the API in this order

1. Model-level API metadata
2. Provider-level API metadata
3. Chat Completions for existing entries without API metadata

The resolved value directly selects /chat/completions or /responses. Model
IDs are passed through as request data and do not affect that decision.

This matches Pi's behavior, where the resolved model API selects the registered
transport. Tau continues to use one OpenAI-compatible provider class with two
internal transports while preserving the same selection behavior.

Compatibility

New providers configured through tau setup or /login custom always receive
an explicit API value. Existing catalog entries without the field continue to
use Chat Completions, preserving compatibility with providers configured before
this option was available.

Configurations that previously depended on names such as gpt-5 or codex to
reach the Responses API should add the following setting.

api = "openai-responses"

Tau leaves existing configuration files intact and applies the Chat Completions
compatibility behavior when API metadata is unavailable.

Documentation

The updated documentation covers

• CLI and TUI setup
• Provider-level defaults
• Model-level overrides
• Existing configuration behavior
• The mapping between Pi and Tau

A development note records the Pi revision used during implementation and the
architectural mapping behind the change.

Validation

• uv run pytest with 1,861 passing tests and 3 platform-specific skips
• uv run ruff check .
• uv run ruff format --check .
• uv run mypy

Closes #546.