👔 Smarter employment_status with new self_employed value + Console updates

• New — employment_status on GET /profile gains a new value: self_employed, for people with no employment relationship but recent income invoices issued under their own RFC.
• Improved — employment_status is now strictly signal-based: employed requires strong evidence of an active employment relationship, and unemployed requires explicit negative evidence — absence of data now yields unknown.
• New — the Console now displays Ingreso mensual estimado (estimated_monthly_income) on the verification detail, inside a new Indicadores calculados section alongside employment status.
• Fixed — the updated_at_to filter on GET /invoices and GET /employments is now inclusive of the entire end day, symmetric with updated_at_from.
• Improved — the Console now shows an accurate error message when the per-minute request limit is reached.

⚙️ What Changes

Redesigned employment_status logic

The employment_status field on GET /profile now follows a strict, signal-based decision order — the first matching rule wins:

1. employed — only with a strong signal of an active employment relationship: a fresh employment record showing active employment (IMSS RPCI / ISSSTE), or recent payroll CFDIs (nómina) received by the person.
2. self_employed (new) — no employment relationship, but the person has recently issued income invoices under their own RFC. Freelancers and independent workers previously hard to classify now get their own status.
3. retired — pension indicator (unchanged).
4. unemployed — only with an explicit negative signal: a successful live IMSS extraction showing no active employment. Absence of data is never treated as unemployment.
5. unknown — no signal in either direction.

This makes each value far more reliable for decisioning: employed and unemployed are now backed by hard evidence, and everything else is explicit about the uncertainty.

Estimated monthly income in the Console

• The verification detail view (tab Perfil) now includes a new Indicadores calculados section grouping the fields we compute for you: Estatus de empleo and Ingreso mensual estimado.
• The income value comes straight from the API's estimated_monthly_income field on GET /profile and is formatted in MXN (e.g. $77,326 MXN). When the field is null, the row is simply not shown.
• The Resumen section is now identity-only: name, CURP, RFC, NSS.

updated_at_to is now inclusive of the full end day

• Previously, updated_at_to was interpreted as T00:00:00Z of the given date, so records updated later that same day were excluded — asymmetric with the inclusive updated_at_from. Example: an invoice updated on 2026-06-20 at 01:05 did not appear with updated_at_to=2026-06-20.
• Now updated_at_to includes the whole ceiling day (internally < to + 1 day), on both GET /invoices and GET /employments. The same query above now returns that invoice.
• If you were compensating by adding one day to your updated_at_to, you can remove that workaround — note that queries with an exact updated_at_to may now return more rows than before.

Clearer rate-limit message in the Console

• When verification creation hits the global per-minute request limit, the Console now shows a specific rate-limit message instead of a generic trial-limit one. Daily-quota messages are unchanged.

🛠️ Action Recommended

• If your integration validates employment_status against a closed list of values, add self_employed to it. Expect the distribution to shift: profiles previously reported as unemployed without hard evidence will now surface as self_employed or unknown.
• Everything else is live with no action needed. The only other behavioral note: updated_at_to now matches the full end day, so freshness-filtered queries may return additional (correct) rows for the boundary date.