PM: tipos LegalPerson, Operator, OperatorRole y OperatorLogin

[rcabrera-py]

Contexto del programa

Portal de banca en línea para legal persons (proyecto Webapp #114).

Modelo acordado:

• legal person (LegalPerson) = US_* en Core (dueña de ledger, cuentas, transferencias).
• Operator = empleado (persona física) en Identify; no es un User de Core.
• Authed autentica al operador y emite Session con user_id = US_empresa.
• Downstream (oaxaca, knox, spider) sigue filtrando por user_id de la empresa — sin cambios de filtrado.

Este issue es la base de contratos que consumen identify, authed, core y webapp.

Naming: el tipo acordado es LegalPerson (traducción al inglés de legal person), no LegalPerson.

Qué hay que hacer

1. Definir enum OperatorRole: operator, authorizer.
2. Request/response LegalPerson (razón social, RFC, representantes — alineado a identify#461).
3. Request/response Operator (email, name, phone, company_user_id, role, status).
4. Request/response OperatorLogin (email + password in; session_token out).
5. Validaciones Pydantic (extra='forbid' en requests).
6. Publicar versión dev (ej. 2.x.devN) para pin en repos dependientes.

Roles MVP (referencia para tipos)

Rol	Descripción
operator	Operaciones excepto autorizar movimientos de dinero
authorizer	Operator + autorizar transferencias/dispersiones

Criterios de aceptación

• Tipos exportados en paquete público (LegalPersonRequest, LegalPersonUpdateRequest, Operator*, OperatorLogin*)
• Tests de validación (casos válidos/inválidos)
• Versión dev publicada o PR mergeable con pin documentado en issue

Dependencias

• Blocks: identify#461–#464, authed#373–Onboarding #375, webapp#19

Asignación

Persona B.

Relacionado

• Tipos transacciones/cuentas oaxaca: cuenca-validations#419 / PR#420
• Session metadata (auditoría TBD): cuenca-validations#422

[gustavo-arzola-cuenca]

legal person es la traducción al inglés