feat: RoutingWorkflow: decouple route and prompt selection, add route descriptions, and rely on structured output.

[JoonasVali]

Summary

• Decouples route selection from prompt selection to enable a more extensible router + workers architecture.
• Improves routing quality by allowing a description per route (beyond labels like “billing” or “technical”).
• Removes JSON guidance from the prompt in favor of the existing structured output contract.
• Clarifies separation of concerns: the ChatClient that selects a route need not be the same ChatClient that processes the task.

Why

The previous example tied a specific prompt directly to a route. This demonstrated routing, but forced a simplistic, non‑extensible design where each task was “solved” by a single specialized prompt. It also returned a prompt to the caller without clearly indicating which route was selected.

What’s changed

• Route selection separated from prompt selection
  • Routing now returns an explicit route choice instead of a prompt, making the selection visible and auditable.
  • Prompt selection becomes an implementation detail/placeholder for real downstream processing.
• Route descriptions added
  • Each route can include a free‑form description to help the LLM disambiguate similar labels and choose more accurately.
• Prompt JSON guidance removed
  • The prompt no longer instructs the model on JSON formatting.
  • Structured output now drives the shape; @JsonPropertyDescription annotations were added to RoutingResponse for field‑level guidance.
• Clearer architecture
  • Explicitly documents that the routing ChatClient can differ from the processing ChatClient, encouraging a router + worker pattern.

The example now better models real systems where routing and execution are distinct phases.

---

Note: Integration test still passes.