Consider explicit provider listing-status policy

Context

Issue #850 broadens the existing model-picker provider-status projection to operator-defined providers with a configured default-model floor. The current eligibility is otherwise encoded through special cases (intentDriven and OpenAI Codex), while some related behaviour remains intentionally intent-driven-only.

Problem

A future provider category may need to decide independently:

• whether it supports live model listing;
• whether listing health is safe and useful to expose publicly;
• whether it receives intent-gateway UX such as available_not_default / organization disclosure; and
• whether it participates in on-demand stale-list refresh.

Encoding each new combination as another boolean predicate risks conflating these policies or exposing built-in provider availability unintentionally.

Potential direction

If a third independently-behaving provider category arrives, consider a small explicit policy on providerEntry (for example a listing-status audience/policy) that declares those independently varying behaviours. Keep it data-driven and avoid an abstraction until that third case exists.

Non-goals

• Do not refactor merely because #850 exists.
• Do not expose raw upstream errors, endpoints, credentials, request arguments, or response bodies.
• Do not change current intent-driven refresh or gateway-disclosure semantics without a separately reviewed decision.

Value

Makes future provider integrations easier to reason about, prevents accidental availability disclosure, and keeps model-picker health, inventory-floor, and gateway-specific semantics distinct.