[frapercan]

Declara 1766b8a4f50418fdc3cf877dd9bb226e70859051 como coordinador y como
schema-applied. Entra PROTEA#1088, ADR-D51.

La migracion es una afirmacion, no una intencion

e3c9a7f15b20 sobre d5a1c8e3f706, 94 a 95 ficheros en alembic/versions.
Aplicada en este servidor antes de abrir esto, desde un worktree en
1766b8a para no mover el arbol servido antes que la declaracion, y comprobada
leyendo la base y no la palabra de alembic:

alembic_version   e3c9a7f15b20
residue_code      existe, 9 columnas, 0 filas
indices           ix_..._sequence_id, ix_..._embedding_config_id,
                  ix_..._shard_key, residue_code_pkey
unico             uq_residue_code_sequence_config

El ensayo en seco dio exactamente una CREATE TABLE, tres indices y el UPDATE
de alembic_version, en una transaccion.

El pin no es la punta, y es a proposito

370f904 es 9b76719 -- lo que este servidor ya corria -- mas un solo commit.
Verificado contra el repositorio: un unico padre, ahead=1 behind=0, y tres
ficheros con cero borrados. ExactAnkh.__init__ solo lee el encoder y las
dimensiones, asi que embed_batch_per_residue no se contamina en el mismo
proceso.

La punta 86e8260 lleva ademas #44 y #45. Reproducido inyectando la punta por
PYTHONPATH sobre el venv servido, sin tocarlo: cinco tests caen, en dos
clases.

• chore(backups): align dump filenames to drill glob + nightly pg_dump installer #45 cambio tokenizer.batch_encode_plus(...) por tokenizer(...), y los
  dobles que solo definen el primero dan KeyError 'input_ids'. Ese si es un
  doble que adaptar.
• chore(FARM-1.7): flip plan status pending -> done #44 no es un doble caduco: es una costura que se mueve con el pin.
  shared_pass_emitter encuentra embed_chunks_multi por getattr, asi que
  compute_embeddings.py:594 toma la ruta compartida y tres tests que parchean
  op._embed_batch dejan de interceptar y conducen el backend real con
  MagicMocks. La docstring de compute_embeddings.py:590 promete que ese parche
  cubre tambien la ruta de grupo, y la promesa solo se cumple en la rama de
  reserva.

Esa subida queda como despliegue aparte.

Una trampa del venv, anotada

El primer pip install --no-deps del commit nuevo devolvio exit 0 y no
cambio nada: pip vio la misma version 0.1.0 ya instalada. La senal no era el
codigo de salida sino direct_url.json, que seguia diciendo 9b76719. Con
--force-reinstall --no-deps dice ya 370f904, torch sigue en 2.12.0+cpu y
pip check esta limpio.

Puerta

0 jobs en QUEUED o RUNNING y ninguna cola de trabajo con mensajes.
protea.dead-letter en 18.775, que son los lotes rechazados de cbaba8bb.
Durante el run la senal de perdida es el delta de esa cola y no el estado
del job: un fragmento que falle la verificacion se nackea sin reencolar
mientras el padre sigue RUNNING sin error.