Fix/typechecker orderby

[jeanpaulduchens]

fix(typing): endurecer el chequeo de ORDER BY contra valores no ordenables

Rama: fix/typechecker-orderby → main
Alcance: typechecker (compile-time). No toca runtime ni tipado global.

Resumen

Cierra un hueco de type-safety en el chequeo de ORDER BY. Ciertos valores
no ordenables (records constantes, agregados que devuelven una lista, y
variables de repetición) se "lavaban" al tipo desconocido ★ en una etapa
previa y pasaban el chequeo de comparabilidad de ORDER BY. En runtime, ese
ORDER BY se ignoraba en silencio, que es justo el caso que ISO/IEC
39075:2024 §4.4.2 marca como data exception 22G04.

El fix tipa esos tres casos con su tipo real localmente en el chequeo de
ORDER BY y los rechaza estáticamente, con un error que cita §22.14.

Motivación

★ está reservado para tipos base (por la relación de precisión, ★ nunca
es consistente con un record ni una lista). Un ★ en una llave de ORDER BY
es sano: siempre es un tipo base, y todo tipo base es ordenable. El problema
es que un valor no base que se lavó a ★ por imprecisión de una etapa
previa se colaba por esa misma puerta. Recuperar su tipo real antes del
chequeo restaura la garantía: un programa bien tipado no falla en runtime por
una llave de orden no comparable.

Rechazar records/listas/nodos/aristas como llave de orden es conforme al
núcleo del estándar, no una limitación arbitraria: ordenarlos requiere la
feature opcional GA04 (Universal comparison, §4.4.2, §22.14), que froGQL no
implementa. Sin ella, esos valores son equality-comparables pero no
ordering-comparables.

Qué cambia

Tres arreglos locales a check_order_by (src/typing/checker.rs), todos
detrás de un helper order_key_type que recupera el tipo real de la llave:

1. Agregado de resultado no escalar. Una llave COLLECT_LIST(x) se tipa
   por el tipo del reductor (List), no por ★, y se rechaza. Los agregados
   escalares (COUNT, SUM, MIN/MAX) siguen aceptándose.
2. Record constante. Un record literal (posible anidado) se pliega a un
   Value::Record que simple_type_of_value lavaba a ★; ahora se tipa como
   Record vía const_order_type, sólo para la llave de orden.
3. Variable de repetición (Group). Una variable ligada por {n,m} no es
   un tipo base; se tipa como Group y se rechaza como llave.

El blast radius es mínimo: la restricción vive sólo en check_order_by.
GROUP BY, DISTINCT y = usan equality-comparability, que nodos, aristas
y records sí tienen, así que ahí no hay restricción (agrupar por identidad de
nodo o por un record sigue siendo válido). El tipado global de constantes
(Expr::Const) queda intacto: RETURN/WHERE/COALESCE siguen viendo un
record constante como ★.

Bajar a un campo escalar sigue siendo válido (ORDER BY r.campo), pero no a
un campo que a su vez es un record (ORDER BY r.sub).

Tests

tests/typecheck_gaps_order_by_test.rs (19 casos, +1 ignorado). Fijan cada
caso: rechazar record / record anidado / lista-agregada / grupo como llave;
aceptar RETURN de un record y ORDER BY sobre un campo escalar; y que los
agregados escalares y los aliases sigan resolviéndose.

Commits

• bebaa9e fix(typing): type ORDER BY aggregate keys by result, reject non-orderable
• 10dea40 fix(typing): reject constant records as ORDER BY sort keys (local hardening)
• 9e1bd16 fix(typing): reject repetition-group variables as ORDER BY sort keys
• bfb35c2 docs(typing): tidy comments, restore simple_type_of_value doc

Pre-commit

cargo fmt --all · cargo clippy --workspace --all-targets -- -D clippy::all
· sweep completo de tests: verde.

Notas para el revisor

• Ninguna consulta cambia de resultado: sólo se rechazan estáticamente
  consultas que en runtime habrían ignorado el ORDER BY en silencio.
• No hace falta que records/grupos devuelvan su tipo real en todo el motor;
  la restricción ★ = base es sólo para orden, por diseño.