feat(rh): db_rh propia + espejo ref_usuario + RBAC por modulo (F1+F2)

F1 - Independizacion del dominio RH (patron db_juridico/db_ventas):

• RH_DATABASE_URL apunta a db_rh; ensure_rh_schema() con DDL idempotente (SQL crudo) crea el mundo nuevo del dominio.
• Espejo ref_usuario (universo: activos con area rh + admins) con 3 vias: upsert-on-auth en require_area("rh"), reconcile masivo (boot + POST /api/rh/ref/reconcile/usuarios) y hook en users.py al cambiar rol/activa/areas. Soft-delete siempre.
• Las tablas legacy de RH (Base) SIGUEN en portal_financiero: rh.py, dashboard.py y empleado_self.py se repuntan de get_db_rh a get_db (mismo destino fisico de siempre; cero migracion de datos).

F2 - RBAC por modulo:

• Tablas modulo (seed: reclutamiento, relaciones_laborales), usuario_modulo (sin_acceso/lectura/escritura) y usuario_rol_rh (rol POR modulo; reclutamiento: gerente_reclutador | reclutadora, validados en _ROLES_POR_MODULO sin CHECK en BD).
• services/rh_authz.py: modulos_efectivos, require_modulo_rh (para adopcion gradual de los modulos), es_gerente_de. Reglas: asignar rol garantiza escritura; perder escritura desactiva el rol.
• routers/rh_roles.py: endpoint "me" + administracion de matriz y roles (admin-gated).
• portal_rh: modal "Permisos RH" por usuario en admin/usuarios (lib/rh_roles.api.ts) espejando las reglas rol/nivel en la UI.

Las pantallas de portal_rh siguen gateando por sub-area OAE; el RBAC queda listo para que Entrevistas de Ajuste (F3) nazca gateada por modulo.