chore(core): remove legacy fallback flags and migrate loop detection (#15213)

docs/cli/model-routing.md

@@ -6,24 +6,20 @@ and provides resilience when the primary model is unavailable.
 
 ## How it works
 
-Model routing is not based on prompt complexity, but is a fallback mechanism.
-Here's how it works:
+Model routing is managed by the `ModelAvailabilityService`, which monitors model
+health and automatically routes requests to available models based on defined
+policies.
 
-1.  **Model failure:** If the currently selected model fails to respond (for
-    example, due to a server error or other issue), the CLI will initiate the
-    fallback process.
+1.  **Model failure:** If the currently selected model fails (e.g., due to quota
+    or server errors), the CLI will iniate the fallback process.
 
-2.  **User consent:** The CLI will prompt you to ask if you want to switch to
-    the fallback model. This is handled by the `fallbackModelHandler`.
+2.  **User consent:** Depending on the failure and the model's policy, the CLI
+    may prompt you to switch to a fallback model (by default always prompts
+    you).
 
-3.  **Fallback activation:** If you consent, the CLI will activate the fallback
-    mode by calling `config.setFallbackMode(true)`.
-
-4.  **Model switch:** On the next request, the CLI will use the
-    `DEFAULT_GEMINI_FLASH_MODEL` as the fallback model. This is handled by the
-    `resolveModel` function in
-    `packages/cli/src/zed-integration/zedIntegration.ts` which checks if
-    `isInFallbackMode()` is true.
+3.  **Model switch:** If approved, or if the policy allows for silent fallback,
+    the CLI will use an available fallback model for the current turn or the
+    remainder of the session.
 
 ### Model selection precedence