[ADD] l10n_latam_check_ux: third party check lifecycle tests

[cav-adhoc]

Primeros dos tests de la batería de regresión de cobros/pagos, como muestra de cómo queda el patrón en el código antes de escribir los veinte.

Qué trae

• test_third_party_check_travels_and_comes_back: recorre cobro → pase de cartera → reversión del pase → endoso → reversión del endoso, verificando en cada paso que el cheque está en una sola cartera, con su importe intacto, y disponible solo cuando corresponde.
• test_third_party_checks_of_equal_amount_do_not_cross: tres cheques del mismo importe se pasan juntos de cartera y ninguno se aplica al apunte de otro.

El patrón que se está probando acá

• El escenario va en el docstring en formato dado / cuando / entonces, con los IDs de escenario que cubre.
• Un subTest nombrado por paso: el rojo dice "endosado a un proveedor deja de estar disponible" en vez de "el test falló". Es la condición que hace legible un test en cadena.
• Comentarios en lenguaje de negocio (por qué el paso importa), no de código.
• Los escenarios que no se implementan quedan declarados en el docstring con el motivo, en vez de desaparecer.

Verificación

Verde sobre una base 19.0 con el módulo instalado: 2 tests, 3,85 s.

Demostrado en rojo: quitando la regla de que una operación de salida deja el cheque fuera de cartera, falla exactamente el paso del endoso, con el mensaje del subTest.

Hallazgos del camino, que no se corrigen acá

1. El orden de operaciones de un cheque se decide por operation_date, que al confirmar se copia de create_date y recibe un offset fijo por pase. Dentro de una misma transacción esos valores empatan y la "última operación" queda definida por el orden del recordset. En producción cada operación ocurre en su propia transacción, así que no se nota; en un test hay que declarar el orden a mano, y dos operaciones dentro del mismo minuto quedarían igual de empatadas en producción.
2. Volver a borrador la entrada de un pase arrastra la salida: los dos pagos van linkeados. Intentar volver las dos por separado falla, porque la segunda ya no es la última operación.

[roboadhoc]

[cav-adhoc]

Actualizado: los dos tests ahora usan la batería de invariantes de account_ux, que va en ingadhoc/account-financial-tools#1017 (misma branch 19.0-t-71623-cav en los dos repos, así el build de runbot los toma juntos). Sin ese PR en el build, el import de AccountInvariantsMixin no resuelve.