Simplify fkl-python: generic IO IOps + let C++ fuse_back fuse (Oscar review)

[johnnynunez]

Contexto

---

Punto 1 — IO genérica en los descriptores de IOp

generate_cu() construía el buffer de entrada/salida con una escalera if/elif cerrada keyed en op.name, que solo cubría un puñado de ops de memoria y duplicaba lógica que pertenece a la propia IOp.

• Cada Read op (_ReadOp) implementa ahora emit_read(state, mem, n_inputs) -> (in_decl, read_expr): construye su propio objeto de buffer host (Ptr2D / Tensor / std::array<Ptr2D,B> / TensorPack / ReadSet) y el build() que lo consume. Una Read IOp es autocontenida, igual que en C++ el buffer viaja dentro del tipo de la IOp.
• Cada Write op (_WriteOp) implementa emit_write(state, mem, pbase) (TensorWrite / TensorSplit / TensorTSplit / SplitWrite).
• generate_cu() ya no tiene escalera: solo llama read_op.emit_read() / write_op.emit_write().
• Se eliminan los cuerpos muertos de TensorRead/Write.cpp() (in_tensor/out_tensor, input.ptr()) que el codegen sobreescribía y nunca llamaba.

Verificación: el C++ emitido es byte-idéntico a main en las 9 variantes de IO (Ptr2D, Tensor-planes, TensorSplit, TensorTSplit, SplitWrite, TensorPack, ReadSet, BorderReader+Crop, batch Crop) × {gpu, cpu}. Como el output no cambia, la caché de compilación se reutiliza (sin recompile storm) y no hace falta bump de CODEGEN_VERSION.

---

Punto 2 — Dejar que C++ fuse_back fusione

executeOperations(stream, iOps...) ya llama internamente a BackFuser::fuse_back(iOps...) (executors.h). El build() sin valor de BorderReader devuelve un IncompleteReadBack, que fuse_back detecta y fusiona con la Read previa vía fk::fuse. Python splicear la expresión de read dentro del BorderReader estaba reimplementando una fusión que C++ hace gratis.

• replicate / reflect / wrap / reflect101 → ahora emiten una IOp IncompleteReadBack plana en la lista y la librería las fusiona. Verificado numéricamente (replicate + crop OOB sigue casando con la referencia CPU, sin splice en Python).
• Excepción honesta — CONSTANT: el builder incompleto BorderReader<CONSTANT>::build(value) no compila upstream (border_reader.h:72 pasa NullType donde se requiere un backIOp; reproducido en aislado con nvcc). La FKL solo soporta la forma completa build(readIOp, value). Para ese único modo se mantiene un splice mínimo (marcador _needs_read), claramente acotado y documentado. Todos los demás modos van por el camino limpio de fuse_back.

CODEGEN_VERSION 7 → 8 (cambia el C++ emitido de los borders sin valor).

Nota sobre lo que no se puede simplificar (honestidad): el threading de tipos en Python (Mul<float3>, Cast<float3,uchar3>, …) es load-bearing, no redundante. No existe ningún Mul<>::build deducido en toda la FKL — los Binary ops exigen <T> explícito. También batch_fuse_head para batch Crop se mantiene: devuelve Read<BatchRead> tipado como ReadType, que fuse_back::idxFirstNonBack no detecta (necesita el fk::fuse explícito). Verificado en el código.

---

Tests (venv del proyecto, GPU RTX PRO 6000 sm_120, nvcc 13.3)

Verde: operations, vertical/horizontal fusion, niche (ambos borders), roi, e2e, circular, dlpack, torch, flash_attention (23), cpu_backend, matrix, thread_fusion.

Las 3 fallas de test_batch_divergent_hf (DivergentHF: …) son pre-existentes en main (bug de selector upstream DivergentBatchTransformDPP, camino de código distinto, no tocado en este PR). Idénticas antes y después.

El tercer commit actualiza la skill fkl-python-extending (arquitectura emit_read/emit_write + el matiz de fusión de BorderReader).

[johnnynunez]

Extra: arreglados los 3 fallos pre-existentes de DivergentHF

Aprovechando el PR, arreglé también las 3 fallas de test_batch_divergent_hf (DivergentHF: …) que venían de main y había marcado como fuera de alcance.

Causa: off-by-one en el selector de secuencias. DivergentBatchTransformDPP es 0-based — exec() llama a divergent_operate<0>(z, seqs...) y ejecuta la secuencia cuya posición 0-based coincide con at(z) (data_parallel_patterns.h; el selector del test de regresión upstream devuelve index==0?0u:1u, o sea 0 elige la PRIMERA secuencia). _selector_cpp emitía el plane_map 1-based tal cual, así que at(0)=1 seleccionaba la SEGUNDA secuencia para el plano 0. Por eso el plano 0 ejecutaba siempre la seq equivocada.

• compose_divergent mantiene el plane_map 1-based en la API (legible); el selector ahora emite (s-1).
• El comentario que citaba circular_tensor.h::SequenceSelectorType como "1-based convention" era incorrecto para este kernel (es otro contrato de selector) — corregido.
• Añadido sv=2 a la firma de caché del divergente para no reusar .so obsoletas del selector buggeado.

test_batch_divergent_hf ahora 12/12 (antes 9/12). circular_tensor (que usa el otro selector), HF y e2e siguen verdes. Suite completa sin fallos.