feat: protocol= parameter for generic protocol-based server access

[Kamilbenkirane]

Summary

Add a protocol= parameter to generate()/analyze()/stream() that lets users target any server speaking a known wire protocol (OpenResponses API, Chat Completions API) without pretending it's a named provider.

# Instead of provider="openresponses" (semantically wrong — it's a protocol, not a provider):
await celeste.text.generate("hello", model="my-model", protocol="openresponses", base_url="https://my-server.com")

# Also for Chat Completions-compatible servers:
await celeste.text.generate("hello", model="my-model", protocol="chatcompletions", base_url="https://my-server.com")

Motivation

Provider.OPENRESPONSES exists in the enum today but is broken — no register_auth, no registered models, create_client crashes with UnsupportedProviderError. The concept of "any Responses-API-compatible server" is valid but doesn't belong in the Provider enum alongside named providers like openai, anthropic, google.

Protocols are wire formats. Providers are entities you authenticate against. These are different concepts.

Scope

1. protocol= parameter — Thread through namespace methods, create_client, resolve to the right client class
2. Move openresponses modality client — modalities/text/providers/openresponses/ → modalities/text/protocols/openresponses/ (it's a protocol, not a provider)
3. Build chatcompletions text-protocol layer — modalities/text/protocols/chatcompletions/ (currently missing — each CC provider reimplements the modality glue)
4. Fix base_url wiring — Currently threaded through signatures but silently discarded at the HTTP layer
5. Auth handling — Generic protocol usage may need NoAuth default + api_key= override
6. Remove Provider.OPENRESPONSES from enum (replaced by protocol="openresponses")

Related

• Discovered during PR feat: unified tools= parameter for tool calling #199 (unified tools= parameter) — the openresponses move was originally bundled there but separated out due to scope