docs(ups): rezultatele testului de autonomie de 15 minute

Al doilea test cu scoaterea din priza (16:08:03 -> 16:23:04, 15,0 min).
Autonomia tot nu e masurata - gauge-ul a coborat doar 90% -> 80% - dar testul
raspunde la intrebarea "pe ce criteriu se opreste serverul".

Trei constatari, toate cu date in document:

(a) Procentul nu are panta pe care sa se poata extrapola: imobil la 90% timp de
    patru minute, apoi 0,8, apoi 2 puncte/minut. Extrapolarea de la minutul 8
    dadea 220 de minute pana la pragul de 35%, cea de la minutul 14 dadea 22.

(b) Saltul de la revenirea curentului se reproduce la aceeasi valoare (65%) in
    ambele teste, dar NU poate opri serverul: blocul de decizie e inauntrul
    ramurii if ($r.OnBattery), iar saltul se produce dupa revenire. Corectez
    aici ce scrisesem in commit-ul anterior - riscul nu e oprirea inutila, ci
    opusul: gauge-ul ramane optimist cat timp bateria chiar se descarca.

(c) BatteryLifeTime e numaratoare inversa, nu masuratoare: 901 secunde scurse,
    872 scazute din estimare (raport 0,97, verificat la trei puncte). Nu aduce
    nimic peste cronometrul propriu al scriptului, deci shutdownAtRuntimeSeconds
    ramane dezactivat - contrar directiei propuse dupa primul test.

Concluzie: timpul pe baterie ramane criteriul principal, procentul ramane plasa
secundara grosiera.

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

docs/ups-server36-monitorizare.md

@@ -175,11 +175,12 @@ powershell -ExecutionPolicy Bypass -File C:\ROMFAST\ups-monitor\ups-monitor.ps1
 | `-Mode TestShutdown` (dry-run) | secvența parcursă integral; Oracle a rămas `Running` |
 | Pierderea comunicației (`test-comms-loss.ps1`) | dispozitiv oprit 15:24:44 → alertă **15:26:44** (exact 8 cicluri × 15 s) + email; reactivare → „comunicația a revenit" + email; `Win32_Battery` înapoi la 1 instanță |
 | Taskul rulează ca SYSTEM | proces `ups-monitor.ps1 -Mode Run`, `state.json` actualizat la fiecare ciclu |
-| **Trecerea reală pe baterie** (scos din priză, 15:47:45 → 15:50:46) | tranziția s-a văzut instantaneu în ambele sensuri; email de pană la 15:47:55, email de revenire la 15:50:56 |
+| **Trecerea reală pe baterie**, de două ori (3 min de la 15:47:45, apoi 15 min de la 16:08:03) | tranziția s-a văzut instantaneu în ambele sensuri, la ambele teste; emailuri de pană și de revenire la fiecare |
 
-Toate cele patru ramuri de alertare au emis email. Testul cu scoaterea din priză a durat doar
+Toate cele patru ramuri de alertare au emis email. Cele două scoateri din priză n-au măsurat
-trei minute — prea puțin pentru autonomie, dar suficient cât să valideze semnalul de sursă și
+autonomia — în cincisprezece minute gauge-ul a coborât doar 90 % → 80 % — dar au validat
-să descopere problema gauge-ului (secțiunea 6, punctul 1).
+semnalul de sursă și au arătat de ce pragul pe procent nu poate fi criteriul principal
+(secțiunea 6, punctul 1).
 
 ### Testul „pe baterie", fără scoaterea din priză
 
@@ -338,39 +339,60 @@ nu are constrângerea asta.
    Pragul corect e „autonomia măsurată minus durata opririi, cu marjă". Până când ambele sunt
    măsurate, pragurile rămân o presupunere rezonabilă, nu o garanție.
 
-   **Ce s-a aflat pe 27.08.2026, dintr-o scoatere din priză de trei minute:** autonomia n-a
+   **Ce s-a aflat pe 27.08.2026, din două scoateri din priză** (3 minute, apoi 15 minute):
-   fost măsurată — trei minute sunt prea puține, iar singura cifră existentă rămâne estimarea
+   autonomia tot **nu e măsurată** — în cincisprezece minute gauge-ul a coborât doar de la
-   proprie a UPS-ului, ~70 de minute, nevalidată. S-a aflat însă altceva, mai important.
+   90 % la 80 %, deci punctul de oprire nici nu s-a apropiat. Singura cifră existentă rămâne
+   estimarea proprie a UPS-ului, ~70 de minute, nevalidată. S-au aflat însă trei lucruri care
+   schimbă alegerea criteriului.
 
-   **Gauge-ul de procent al acestui UPS nu e de încredere.** Pe baterie a scăzut lent și
+   **(a) Gauge-ul de procent nu are o pantă pe care să se poată extrapola.** În testul de 15
-   monoton (100 % → 96 % în trei minute), dar la revenirea curentului a sărit haotic:
+   minute a stat blocat pe loc patru minute, apoi a accelerat de aproape zece ori:
+
+   | Interval | Pantă |
+   |---|---|
+   | 16:08 → 16:12 (4 min) | **0** puncte/min — imobil la 90 % |
+   | 16:12 → 16:17 | 0,8 puncte/min |
+   | 16:20 → 16:23 | **2** puncte/min |
+
+   Extrapolarea făcută la minutul 8 dădea „pragul de 35 % vine peste 220 de minute"; cea de la
+   minutul 14 dădea 22 de minute. Aceeași baterie, aceeași sarcină, zece minute distanță.
+
+   **(b) La revenirea curentului sare haotic — reproductibil, la aceeași valoare.** Ambele
+   teste, independent:
 
    ```
-   15:50:26  baterie 96%
+   test 1:  96 %  ->  65 %  ->  75 %  ->  90 %      în ~100 s
-   15:50:46  rețea   65%     <- revine curentul
+   test 2:  78 %  ->  65 %  ->  70 %  ->  75 %      în ~45 s
-   15:51:06  rețea   75%
-   15:51:46  rețea   90%
    ```
 
-   96 → 65 → 90 în 100 de secunde. Nicio baterie nu se încarcă 25 de puncte în 80 de secunde,
+   Nicio baterie nu se încarcă 25 de puncte în 80 de secunde; e recalibrare, nu încărcare.
-   deci nu e încărcare — e recalibrare, sau zgomot în jurul tranziției. (La 12 minute după test
+   **Acest zgomot nu poate opri însă serverul**: tot blocul de decizie a opririi e înăuntrul
-   gauge-ul era tot la 90 %.)
+   ramurii `if ($r.OnBattery)` (`ups-monitor.ps1`), iar saltul se produce după revenirea
+   curentului, când ramura nu se mai execută. Pericolul real e opus și e demonstrat de punctul
+   (a): gauge-ul **rămâne optimist** cât timp bateria chiar se descarcă — opt minute și
+   jumătate blocat la 90 % — deci un prag pe procent reacționează prea târziu, nu prea devreme.
 
-   **Consecința pentru configurația actuală:** pragul de **35 %** se sprijină exact pe numărul
+   **(c) `BatteryLifeTime` nu e o măsurătoare, e o numărătoare inversă.** În testul de 15
-   ăsta nesigur, iar garda de confirmare (`confirmPolls = 3`, adică 45 s) e **mai scurtă decât
+   minute au trecut 901 secunde, iar estimarea a scăzut cu 872 — raport 0,97, verificat și la
-   fereastra de zgomot observată (~80–100 s)**. Riscul e în ambele sensuri: o citire aberantă
+   două puncte intermediare (240/240 s și 871/872 s). UPS-ul fixează o valoare la începutul
-   sub 35 % ar putea opri inutil baza de producție, iar una optimistă ar putea întârzia
+   penei și scade timpul scurs din ea. Nu aduce nicio informație peste cronometrul propriu al
-   oprirea.
+   scriptului, iar dacă estimarea inițială e greșită, numărătoarea e greșită cu exact aceeași
+   eroare până în secunda în care se stinge.
 
-   Semnalul de **sursă** (`ACLineStatus`) a fost, în schimb, impecabil — tranzițiile s-au văzut
+   Semnalul de **sursă** (`ACLineStatus`) a fost, în schimb, impecabil în ambele teste —
-   instantaneu în ambele sensuri. De aici, direcția pentru pragurile definitive:
+   tranzițiile s-au văzut instantaneu în ambele sensuri, iar emailurile au plecat la fiecare.
+   De aici, direcția pentru pragurile definitive:
 
-   - **timpul pe baterie devine criteriul principal**, fiindcă se sprijină pe `ACLineStatus`;
+   - **timpul pe baterie rămâne criteriul principal**, fiindcă se sprijină pe `ACLineStatus`,
-   - procentul rămâne doar plasă secundară, cu valoare mai mică și cu `confirmPolls` crescut
+     singurul semnal care s-a purtat impecabil;
-     peste fereastra de zgomot (≥ 8 cicluri = 2 min);
+   - **`shutdownAtRuntimeSeconds` rămâne `0` (dezactivat)** — punctul (c) arată că ar fi doar
-   - de evaluat `BatteryLifeTime` ca al treilea criteriu — în acest test a scăzut lin și
+     al doilea nume al aceluiași cronometru;
-     monoton, spre deosebire de procent. Există deja `shutdownAtRuntimeSeconds` în
+   - procentul rămâne plasă secundară grosieră. Nu are rost coborât mult sub 35 %: fiind
-     `config.json`, momentan `0` = dezactivat.
+     optimist, nu aberant, el oricum nu declanșează primul.
+
+   Ce ar schimba concluzia: o măsurătoare dusă până la o descărcare adâncă, unde s-ar vedea
+   dacă gauge-ul se prăbușește brusc spre final. Pe o bază de producție asta nu se face fără
+   fereastră de mentenanță.
 2. **Vârsta acumulatorilor.** Necunoscută. Pe cluster există deja criteriul de vârstă în
    testul lunar (`proxmox/cluster/ups/`); aici nu există nimic echivalent.
 3. **BIOS: *Restore on AC power loss*.** De verificat la prima intervenție fizică — altfel