La declaracion a 06582be: el orden del banco de donantes

[frapercan]

Decimoctavo salto, de 92866b6 a 06582be. Tres PR de PROTEA.

#1006, correccion de cifras sobre #1004, sin comportamiento: known-terms.tsv
son 5.206.444 filas y 95.038.180 bytes, no 2.235.489 y 43,6 MB. La medida
original fue una transferencia truncada al 46% por el kill de la API del salto
anterior, hecha con curl -s | wc -l, que cuenta lo que llegue y no puede
informar de un corte.

#1007 + #1008, el banco de donantes no tenia orden. El 91% de las consultas
tienen vecinos a distancia ~0, ellas mismas o gemelas con la misma secuencia, asi
que los candidatos empatan en el k-esimo hueco y gana el donante que vaya
primero en el banco. Cuatro sitios lo decidian por accidente:

1. la consulta del pool sin ORDER BY: medido sobre el banco de la 219, 142.422
   filas identicas, hash join da 89b79ad15383 y merge join cf77c750bed5, que
   es exactamente el orden por accesion;
2. el array de indices por aspecto, iterando un set de cadenas, con el hash
   de cadenas aleatorizado por proceso y PYTHONHASHSEED sin fijar: tres
   interpretes, tres ordenes, en cada arranque de worker;
3. la colacion: en_US.utf8 pone A0A18 antes de A0A1-9, mientras sorted()
   de Python es codepoint, asi que las dos mitades del arreglo no coincidian
   entre si;
4. las listas de anotaciones por donante, que se aplanan posicionalmente en el CSR
   de disco y de las que el candidato toma su evidence_code.

_CACHE_EPOCH pasa de 3 a 4, y es la mitad sin la cual el resto no sirve. El
orden es invisible a los tres guardas de la cache, incluido un pool_fingerprint
calculado sobre las accesiones recien cargadas de esa misma cache. Medido antes
del salto: 142.422 accesiones sin ordenar y los tres .pool con
901a354f173edfa9, donde el ordenado da dc280304d5dce097.

Para el nodo

Los ficheros de data/ref_cache bajo e3 quedan inalcanzables, no corruptos.
Se pueden borrar o dejar; el primer predict reconstruye bajo e4 y paga una
carga de banco, unos 63 s en el portatil. Si el nodo ordena bancos por su cuenta,
que sea por accesion en orden de codepoint, no por la colacion de una base.

Ni migraciones ni modelos entre los dos shas, la base sigue en f2a8c41d9e37, y
pyproject.toml y poetry.lock sin tocar, asi que protea-sources se queda en
fc43ab94.