test(storage): PendingSearchEchoPaths tests dependen del segundo de last_indexed (flaky en CI) #189

Problema

TestPendingSearchEchoPathsRequeuesZeroValuedCodexShellSerializedWhitespace (internal/storage/search_echo_test.go:249) falla de forma intermitente en CI y bloquea el check requerido candidate. Ocurrió en el PR #188, run 38786295313:

search_echo_test.go:315: pending=[sep_space.jsonl sep_tab.jsonl sep_cr.jsonl sep_em_space.jsonl sep_en_space.jsonl sep_ff.jsonl sep_nbsp.jsonl sep_nbsp_lc.jsonl sep_newline.jsonl] want [sep_cr.jsonl sep_em_space.jsonl ... sep_tab.jsonl]

El conjunto es idéntico; solo cambia el orden.

Causa

stalePathsContext (internal/storage/queries.go:954) ordena por indexed_files.last_indexed ASC, search_items.source_path ASC. Ese orden FIFO es el contrato de drenado incremental. last_indexed es CURRENT_TIMESTAMP, con resolución de un segundo. Cuando SyncFiles cruza un borde de segundo, los primeros archivos quedan con un timestamp menor y salen antes. El test asume orden alfabético puro, y eso solo se cumple si todos los archivos caen en el mismo segundo.

Alcance

• Los tests de PendingSearchEchoPaths/StalePaths cuya intención es el conjunto de rutas reencoladas comparan como conjunto (ordenando got y want). Revisar también search_echo_test.go:168, :228, :407, echo_parity_test.go:174 y relaxation_echo_idf_test.go:387.
• Si existe un test cuyo objetivo es el orden FIFO, fija last_indexed explícitamente para que el orden sea determinista.
• Sin cambios de código de producción.

Criterios de aceptación

• go test -race -count=50 -run 'PendingSearchEcho|StalePaths|EchoParity|RelaxationEcho' ./internal/storage pasa 50/50.
• go test -race -count=1 ./internal/storage pasa.