Verificare ANAF la alegerea partenerului: 404, disponibilitate serviciu (docs)

Design doc REVIZIA 5: contractul 404 (verdict "inexistent" doar cand raspunsul
contine chiar codul cerut), starile serviciului pe sesiune si banda cand ANAF nu
raspunde, cache doar pe verdicte pozitive, codul nenumeric.

Changelog: intrarea 2.11.65 descrie comportamentul asa cum ajunge la utilizator -
functionalitatea nu a fost inca livrata, deci corectiile din interiorul ei nu se
pomenesc separat.

TODOS: contractul 404 pe drumul batch (P4) si verificarea dupa tara partenerului
(P5), amanate explicit.

Codul: COMUN 95cf54e.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DhJwsrFFe1ZNAAtS8Twuti

TODOS.md

@@ -92,3 +92,40 @@ Sursa: `docs/design-alegere-partener-anaf.md`, REVIZIA 4 (implementata doar nive
 - **Cerinte tehnice deja verificate** (de nepierdut la implementare) — sectiunea 8 din
   `docs/design-alegere-partener-anaf.md`: UC1, D-F2, C4, H1, H4, H5, H8, H9, M1, M7.
 - **Efort:** L. **Depinde de:** masuratorile de mai sus.
+- **Masurat partial (27.07.2026)**, vezi `docs/plan-reparatie-anaf-404-breaker.md`: latenta
+  unui apel la ANAF sanatos 0,08 s; gazda care inghite pachetele 21,05 s fara timeout-uri,
+  4,00 s cu SetTimeouts(2000,2000,3000,3000); WinHTTP asincron `Send()` 0,009 s,
+  `WaitForResponse(0)` 0 s. Ramane nemasurat comportamentul la rafale (de la al catelea 429).
+
+## P4 — Contract 404 pe drumul batch ANAF (D406 si sincronizari)
+- **Ce:** `validare.prg:1827` citeste corpul raspunsului doar pe `Status = 200`, la fel cum
+  facea si wrapper-ul single-CUI. Pe loturi, un CUI inexistent si o cadere de serviciu ajung
+  la utilizator ca acelasi lucru ("nu s-a putut verifica").
+- **De ce:** masurat 27.07.2026 — ANAF intoarce HTTP 404 cu corp complet
+  `{"found":[],"notFound":[<cui>]}`, deci informatia exista, doar e aruncata. Regula corecta,
+  stabilita si implementata pe calea single-CUI: verdict "inexistent" doar cand `notFound`
+  contine chiar codul cerut (`notFound` apare si in raspunsurile de succes, ca tablou gol).
+- **Ce s-a facut deja in transa din 27.07:** doar timeout-urile pe calea batch (~105 s de
+  fereastra inghetata devin ~20 s pe 500 de coduri). Logica de verdict nu s-a atins.
+- **De ce nu acum:** atinge interpretarea raspunsului in D406 si in sincronizari, deci cere
+  runda proprie de teste pe declaratie, nu doar pe formularul de cautare.
+- **Efort:** M. **Depinde de:** transa `plan-reparatie-anaf-404-breaker.md` (regula notFound).
+
+## P5 — Verificare ANAF dupa tara partenerului (punctul D)
+- **Ce:** tara partenerului adusa in cursorul de cautare, ca `cod_tara` caracter (gol sau `RO`
+  = se verifica), in locul euristicii pe primele doua litere din codul fiscal.
+- **De ce:** dupa reparatia din 27.07, un partener extern cu cod pur numeric ajunge la ANAF si
+  poate primi verdict rosu "Cod fiscal inexistent la ANAF". In MARIUSM_AUTO: 2825 parteneri,
+  dintre care 21 cu alta tara — suprafata mica, dar reala si acum vizibila.
+- **Decizii deja luate (nu se redeschid):** se verifica dupa tara, nu dupa literele codului;
+  tara necompletata = Romania; respinse explicit de Marius — functie noua cu query per partener
+  si selectia din `VNOM_PARTENERI` ("prea multe join-uri in adresa"). `VALIDARE_CIF` nu se
+  atinge in nicio varianta (folosita in toata suita).
+- **Ramas de facut:** lantul scurt `NOM_PARTENERI → ADRESE_PARTENERI (principala=1) →
+  SYN_NOM_LOCALITATI → SYN_NOM_JUDETE → SYN_NOM_TARI.PRESCURTARE`, masurat fata de cautarea de
+  azi (28 ms pe filtrul `cont='401' and denumire like 'FA%'`); al doilea drum,
+  `CautPartenerContabilitate` (`ocautare.prg` ~890-960), selecteaza direct din tabela si cere
+  join separat.
+- **Conditie de intrare:** reclamatii pe parteneri externi marcati rosu, vizibile in logul de
+  discordante (`anaf_verif_cautare`).
+- **Efort:** M. **Depinde de:** masuratoarea lantului scurt.