refactor: decompose LLMRails & LLMGenerationActions into modular components

[Pouyanpi]

Description

Currently we have two enormous classes, LLMRails (~2000 LOC) and LLMGenerationActions (~1200 LOC), that each do dozens of unrelated things (config loading, model init, DSL parsing, prompt templating, LLM calls, streaming logic, event translation, post-processing, etc.). This makes the code hard to understand, test, and extend.

Goal: break each of these “God classes” into a set of well-defined, single-responsibility modules. For example (this is just to show the idea and will change):

• ConfigLoader (load & validate flows, ingest config.py overrides)
• ModelFactory (instantiate LLM(s), set streaming flags)
• KnowledgeBaseBuilder (async build of embeddings index)
• EventTranslator (messages ⇄ events for v1/v2)
• PromptRenderer (Jinja context & templating)
• LLMClient (one entry‐point for llm_call → parse → clean)
• RuntimeOrchestrator (invoke Colang runtime, handle sync/async, retries)
• ResponseAssembler (assemble GenerationResponse or stream chunks)
• RailsFacade (thin API layer wiring them together)

Acceptance criteria:

• all existing behavior preserved (CI green, no regressions)
• each new component has its own public interface and unit tests
• no more classes > 500 LOC with mixed concerns (LOC does not really matter but SRP does)
• global mutexes/threads/“if True or …” hacks eliminated

[azibek]

Hi @Pouyanpi, I feel the pain of dealing with god classes, and would like to help out with this mammoth refactoring. Can you assign it to me?

[Pouyanpi]

Thank you @azibek for your interest, much appreciated. These kind of issues require decisions and design from our team. But you are always welcome to contribute to NeMo Guardrails, we will label more issues with "help wanted" and "good first issue" so that we can benefit from your great contributions 🥇