[frapercan]

e61a26e4 -> 5896310. Un PR de PROTEA, #1069, sin migracion y sin cambio
de dependencias ni de frontend.

Lo que desbloquea

El codigo aprendido llevaba la noche almacenado, 684.048 vectores de 8192
dimensiones con exactamente 64 no nulos por fila, sin un solo numero contra
el. El tapon no era la busqueda:

banco denso float32              22,41 GB
el mismo en CSR                   0,35 GB     factor 64
f16 + f32 + f32_cos a la vez     56,00 GB     en una maquina de 30 GiB

disk_cache._derive_reference_views construye la copia f32 antes del
if need_cos y solo la suelta en el return, asi que need_plain=False no
evitaba la asignacion.

protea_method.knn_search queda intacto: su backend numpy acepta un
csr_array tal cual, verificado con el mismo orden de vecinos y delta
0,000e+00.

Lo declarado, y por que no sparse

La libreria tiene ya un backend sparse escrito para codigos k-WTA y
deliberadamente no se usa: search_backend es campo de
METHOD_IDENTITY_FIELDS, asi que elegirlo haria que el brazo del codigo
aprendido difiera del de ankh-base en dos campos declarados en vez de uno y la
comparacion perderia su eje.

Sin cache de disco, declarado como alcance

El formato es np.save; el modulo exige subir una constante cuando cambia el
SIGNIFICADO de lo cacheado y registra dos incidentes en que no se subio y se
sirvio lo viejo bajo clave valida; y cualquier desajuste se vuelve un MISS
permanente silencioso. Cuesta 10,1 min cargar el banco entero a 0,88 ms por
fila, contra 12,6 min del banco denso de ankh-base que si se cachea.

Sin migracion

Nada toca alembic/. La base se queda en d5a1c8e3f706.

Puerta comprobada en el servidor

0 jobs QUEUED o RUNNING y ningun prediction_set escribiendose.