fix(gitnexus): reindexar no puede borrar los embeddings, y se verifica al final

[wolverin0]

El riesgo

npx gitnexus analyze sin --embeddings no los deja como estaban: los borra. Hoy son 12.079 y regenerarlos es caro.

Dónde NO estaba el problema

Mi primera lectura culpó al hook de Claude Code. Estaba equivocada — gitnexus-hook.cjs:284 ya arma el comando bien:

const analyzeCmd = `npx gitnexus analyze${hadEmbeddings ? ' --embeddings' : ''}`;

Dónde sí está

En los docs del propio repo. AGENTS.md y CLAUDE.md muestran el comando pelado en dos lugares — línea 95 ("run npx gitnexus analyze in terminal first") y el bloque Keeping the Index Fresh.

Y ahí está lo que descarta el arreglo obvio: ese texto vive dentro de <!-- gitnexus:start -->, que el propio analyze reescribe. Corregirlo a mano dura hasta el próximo reindex. Esto no se arregla documentando.

Lo que sí sobrevive a la regeneración

Una vía que no depende de recordar el flag, y que verifica el invariante después de correr:

Función	Qué fija
analyze_command(n)	El flag se decide por el conteo real del índice, no por memoria
verify_preserved(before, after)	Compara contra el conteo previo, no contra cero
embedding_count()	Un meta ausente o ilegible es 0, no una excepción

El detalle que importa en verify_preserved: un índice que pasó de 12.079 a 3 está roto igual, y un chequeo ingenuo (after > 0) lo daría por bueno. Por eso la comparación es contra el conteo anterior.

Recordar un flag es una esperanza; verificar el conteo después es un hecho.

Verificación

9 tests. Y 4 mutaciones, cada una desactivando una decisión:

Mutación	Muere por
Nunca agrega --embeddings	test_con_embeddings_el_flag_no_es_opcional
Lo agrega siempre	test_sin_embeddings_no_se_agrega_el_flag
Sólo detecta pérdida total	test_detecta_la_perdida_PARCIAL
Da por bueno cualquier resultado	test_detecta_la_perdida_total

Contra el índice real: reporta 12.079 y arma el comando con el flag. Ruff limpio.