atuq: el contador de caídas es un TALLY — 0 · 1 · 2, y lo suma el arranque siguiente

Lo que el §6.10.terdecies dejaba escrito como «todavía NO medido» quedó medido: tres fases de 60 s en
un mismo arranque, cada una matada con kill -9 antes de pintar, dan contador 0 · 1 · 2. Uno por
arranque interrumpido y sin techo.

Dos cosas que la serie sola no distinguía, y que valen más que el número:

· el incremento lo escribe el arranque SIGUIENTE, no el kill — el «después» de la primera fase sigue
  ausente (el navegador estaba vivo) y el 1 aparece recién en la segunda. Quien cuenta es el que
  arranca y encuentra el anterior sin terminar;
· un arranque que sigue a una corrida SANA no suma. Eso separa «cualquier arranque incrementa» de
  «sólo después de uno interrumpido», que es la diferencia entre culpar al kill y culpar al arranque
  que no llegó a terminar.

Queda dicho qué sigue sin medir: si la comparación con `max_resumed_crashes` va antes o después del
incremento del propio arranque. Las dos lecturas dan «cuatro interrumpidos seguidos» en la práctica;
la diferencia es poder decir el número sin inventarlo, y se está midiendo cruzando el umbral en vivo.

Medido por la otra sesión del frente (work/contador-1.txt), con la predicción escrita antes de mirar.

docs/26-atuq-envoltorio-gecko.md

@@ -2140,9 +2140,33 @@ diálogo**. Con 16 acumulados, todo lo medido desde el 14-Sep cae bajo sospecha:
 del §6.10.septies y «2 de 10» del §6.10.nonies no midieron intermitencia del producto sino **un
 perfil que se degradaba corrida a corrida**. El instrumento degradaba al sujeto.
 
-(**Lo que todavía NO está medido**, y se dice para que no se lea como medido: que cada corrida
-matada sume exactamente uno. La medición que lo cerraría es una corrida sin `--crashes`, matada a
-mitad, y leer el contador del arranque siguiente con `debugfs`.)
+**Y eso quedó MEDIDO el mismo día** (tres fases de 60 s en un mismo arranque, cada una matada con
+`kill -9` **antes** de pintar — o sea antes del gancho que cierra la detección de caída de arranque):
+
+| fase | contador antes | después | qué la precedió |
+|---|---|---|---|
+| k1 | ausente | **ausente** | una corrida SANA, que terminó bien |
+| k2 | ausente | **1** | k1, matada antes de pintar |
+| k3 | 1 | **2** | k2, matada igual |
+
+Es un **tally**: uno por arranque interrumpido, sin techo. Y trae dos cosas que la serie sola no
+distinguía:
+
+- **el incremento lo escribe el arranque SIGUIENTE, no el kill.** Se ve en que el «después» de k1
+  sigue ausente —el navegador estaba vivo todavía— y el 1 aparece recién en el «después» de k2.
+  Quien cuenta no es el que muere sino el que arranca y encuentra el anterior sin terminar; de ahí la
+  consistencia interna de la serie, `antes(k3) = después(k2) = 1`;
+- **un arranque que sigue a una corrida sana no suma** (k1). Eso separa «cualquier arranque
+  incrementa» de «sólo después de uno interrumpido», que es la diferencia entre culpar al kill y
+  culpar al arranque que no llegó a terminar.
+
+⚠ **Lo que sigue sin medir es el BORDE**, y se dice para que no se lea como medido: el diálogo aparece
+cuando el contador vale más que `max_resumed_crashes`, pero no está comprobado si la comparación se
+hace **antes o después** del incremento de ese mismo arranque — o sea si el diálogo sale en el
+arranque que EMPIEZA valiendo 3 (compara después de sumar) o en el que empieza valiendo 4 (compara lo
+guardado). Las dos dan «cuatro arranques interrumpidos seguidos» como respuesta práctica, y
+distinguirlas importa sólo para poder decir el número sin inventarlo. Se mide cruzando el umbral en
+vivo, que es lo que está en curso.
 
 Qué se hizo con eso, en vez de borrar el fichero: