Por qué falla setState en un StatelessWidget y cuándo es obligatorio dar el salto a StatefulWidget

Al intentar añadir interactividad y variables mutables dentro de un StatelessWidget (por ejemplo, una variable _colorActual y una función que invoque setState()), el analizador de Dart interrumpe de inmediato la compilación con dos errores característicos:

The method 'setState' isn't defined for the class '...': El método setState no existe en la jerarquía de StatelessWidget.
This class is immutable, but has fields that aren't final: Las clases que heredan de StatelessWidget deben ser estrictamente inmutables (todos sus campos deben ser constantes o marcados como final).

El intento erróneo habitual

class MainApp extends StatelessWidget { // Widget inmutable sin soporte para estado local
  Color _colorActual = Colors.blue; // Error: Los campos en StatelessWidget deben ser obligatoriamente final

  void _cambiarColor() { // Método que intenta mutar el estado
    setState(() { // Error: setState no existe ni está definido en StatelessWidget
      _colorActual = (_colorActual == Colors.blue) ? Colors.green : Colors.blue; // Intento de mutación
    }); // Fin de setState
  } // Fin de _cambiarColor

  const MainApp({super.key}); // Constructor constante
} // Fin de la clase MainApp

¿Por qué sucede y cómo se soluciona?

Un StatelessWidget se instancia, ejecuta su método build() para devolver una descripción visual inmutable y no retiene memoria de cambios en el tiempo. Carece deliberadamente de infraestructura de mutabilidad para ser ultraligero.

Para retener variables mutables en memoria viva y avisar al framework de que debe repintar la interfaz con nuevos valores, Flutter exige una estructura dividida en dos clases: una que hereda de StatefulWidget y su correspondiente objeto de estado State<T>.