La rotación no parece funcionar bien, cuando un comportamiento de dirección devuelve una cierta aceleración angular en grados/segundo

[federicopeinado]

A la hora de programar Alineamiento (una clase importante en Millington porque es la base de algunas otras), no parece que Agente responda bien cuando le damos aceleración angular (en algunos casos el personaje rota a gran velocidad y sin mucho control.... en otros directamente no rota nada). Seguramente hay algún ERROR EN EL CÓDIGO por la manera en que se le asigna el torque (¿estamos teniendo en cuenta que la aceleración angular no es más que un valor real positivo o negativo que representa los grados por segundo en un sentido o en otro que hay que cambiar la orientación del agente?), o si simplemente es un problema de inercia (aunque tengamos Llegada Angular, funciona igual que Llegada Lineal: lo único que hacemos a lo sumo es decelerar hasta imprimir una aceleración de cero pero NO estamos proponiendo aceleraciones negativas que deberíamos proponer también, ojo).

El error más grave parece este: en FixedUpdate, estamos aplicando un torque (aceleración angular física) con AddTorque... pero inmediatamente después llamamos a LookDirection(), una función que SOBREESCRIBE transform.rotation usando un suavizado (SmoothDampAngle) basado en la dirección del movimiento lineal; además hecho de tal manera que SÓLO ROTO cuando me estoy moviendo linealmente y siempre en el sentido de mi movimiento ¡Esto no deberíamos hacerlo en Agente, habría que quitar ese LookDirection directamente... y si alguien lo quiere hacer, que use un steering behavior para ello!
Por si acaso, confirma también que en Unity el Rigidbody tenga algo de Angular Drag (rozamiento angular) en el Inspector (un valor entre 0.5 y 2.0 o algo así, para estabilizar y evitar rotaciones descontroladas...)

El código quedaría algo así:
if (Mathf.Abs(direccion.angular) > 0.01f) // Un pequeño umbral para evitar jitter, eso sí
{
float torqueAAplicar = Mathf.Clamp(direccion.angular, -aceleracionAngularMax, aceleracionAngularMax);
cuerpoRigido.AddTorque(Vector3.up * torqueAAplicar, ForceMode.Acceleration);
}

Otro error posible es que no se está controlando bien los límites de la aceleración. En estas líneas de código no se tiene en cuenta que si la aceleración angular es NEGATIVA también debe limitarse... y eso habría que cambiarlo:
if (direccion.angular > aceleracionAngularMax)
direccion.angular = aceleracionAngularMax;
Osea, habría que hacer algo parecido a: direccion.angular = Mathf.Clamp(direccion.angular, -aceleracionAngularMax, aceleracionAngularMax);

Otra cosita más es corregir un error de lógica en el límite negativo al calcular la velocidad angular... habría que hacer algo así:
float velAngularActual = cuerpoRigido.angularVelocity.magnitude;
if (velAngularActual > rotacionMax)
{
cuerpoRigido.angularVelocity = cuerpoRigido.angularVelocity.normalized * rotacionMax;
}

[federicopeinado]

Algunos han comentado que el problema podría estar en la ANIMACIÓN del perro, que es una especie de rotación que oscila hacia un lado y hacia otro (especialmente rápida cuando el perro está en movimiento). Sin embargo entiendo que la animación que tiene la malla del perro NO debería interferir en su movimiento y rotación, porque la animación rota LA MALLA del perro, pero no el perro en sí como GameObject, mientras que todos vuestros comportamientos de dirección trabajarán sobre el perro como GameObject/Agente (¡Cuidado no añadáis un ANIMATOR al Perro!). Vamos, que lo que se rota es el PIVOTE exacto del Perro, y no el "CENTRO" del prefab (importante distinguir entre pivote y centro en Unity).

[federicopeinado]

Recopilación de mejoras que han ido saliendo: hay por ahí un Models.meta huérfano, algún material dentro de la carpeta Textures y quizá habría estado bien tener Kaykit en una carpeta llamada ThirdParty. El código se podría separar en carpetas Base, Game y UI, por ejemplo, o usando un namespace propio para todo lo que sea la base de la práctica. En cuanto a nomenclatura, deberíamos haber quitado las eñes de los nombres (Montaña), aparte de elegir español o inglés para nombrarlo todo y ser sistemáticos... también usando PascalCase. En la parte de la UI convendría evitar nombres poco descriptivos, y en el código la dependencia con los nombres de los objetos, no usando GameObject.Find() que tiene mucho peligro. En cuanto al código cada recarga de escena crea otro listener en inputRatas que puede ser problemático, como también me parece que lo puede ser el if (cuerpoRigido != null) en Agente.LateUpdate() o el hecho de que angularVelocity.magnitude nunca sea negativa en Agente.FixedUpdate(). Conviene añadir chequeos de que no te pasan null (NullReferenceException... por seguridad hay que comprobarlo). En TocarFlauta hay una static List compartida que podría dar problemas si no se limpia bien en reinicios/cambios de escena. Quizá hay mucho GetComponent repetido en callbacks/Update que convendría cachear, y quizá también hay imports sin usar en algunos scripts.
Como se explica más arriba, el código de Agente tal y como está obliga a encarar en dirección al movimiento lineal, tanto con el LookDirection() de Update y FixUpdate, como con el transform.LookAt(...) de LateUpdate.