Generalize apiKeyOptional across custom provider kinds

Context

#109 added apiKeyOptional: true for custom Anthropic entries only. The anthropic-only scoping was deliberate — it's the only additional kind with wire-level anonymous support — but it introduces per-kind special cases that would disappear if the option were general:

• schema.ts: the field is bolted onto the anthropic variant via .extend() instead of living in the shared customProviderVariantSchema factory; fragments may carry it for any kind but only anthropic survives merged validation.
• resolve-catalog.ts: resolveAuthPolicies needs the entry.type === "anthropic" ? entry.apiKeyOptional : undefined conditional.

Generalizing would remove those, but most of #109's bulk is scoping-independent and stays: ResolvedCustomAuthPolicy + provenance resolution, the CUSTOM_KIND_API_KEY_OPTIONAL_DEFAULT mirror + shape guard, the watcher classification, and the wire-level client handling.

What generalizing requires

The per-kind work relocates rather than vanishes: each newly-supported kind needs its own anonymous-mode wire handling (the Anthropic sentinel/header-strip exists because the SDK falls back to ANTHROPIC_API_KEY; the OpenAI SDK has the same OPENAI_API_KEY fallback problem), plus wire-level tests proving no auth header or ambient env var leaks. Kinds already key-optional by default (openai-compatible, litellm, portkey) would treat the field as redundant-but-harmless.

Why do it

• Removes the schema/resolution special cases above (small win, ~20-30 lines plus comments).
• Avoids a schema migration later if more kinds gain anonymous support.
• Natural stepping stone toward posit-dev/assistant-feedback#102, which asks for apiKeyOptional on built-in providers (built-in anthropic/openai/gemini pointed at a pre-authenticated corporate gateway). The layered-config provenance machinery from #109 already generalizes; the remaining work is per-protocol wire behavior and UI surfaces accepting a blank key.

Not urgent — file for future consideration.

Start with schema.ts and resolve-catalog.ts, then trace the resolved-policy, default-shape-guard, watcher, and wire-handling paths introduced by #109. Identify each newly supported provider kind and its anonymous-mode behavior, including wire-level tests that verify no auth header or ambient environment variable leaks. Done means the schema and resolution logic are kind-independent while each supported protocol handles anonymous requests safely.