SDD 28 §6.13: takana upgrade probado de verdad — apply, rollback y un corte duro

Probado con un paquete que la caja necesitaba (`zstd-cli`): apply deja generación, la caja pasa a
desempacar su propio lab, `rollback` devuelve el estado anterior fichero a fichero (9 restaurados,
1 borrado), y tras el arreglo de durabilidad **sobrevive a un `hcloud server reset`, que es un corte
DURO y no un apagado limpio**.

Y cruza la frontera que `hydrate` no puede: store en el volumen, `/` en el disco local. Es el único
camino de actualización que funciona en una caja instalada.

El bug que destapó está en el commit anterior: `write_atomic` era atómico frente a otros procesos y
no frente a un corte, así que el primer upgrade se perdió al reiniciar y `recover` abortaba con la
huella misma del corte. Verificado en la máquina en los dos sentidos: binario viejo ⇒ estado en 0
bytes; binario nuevo ⇒ estado íntegro.

`recipes/takana.toml` re-pineado al commit del arreglo.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RomoxEGZUhaT4pob1QSX5x

recipes/takana.toml

@@ -35,7 +35,7 @@ license = "MIT"
 # El repo del propio takana: el `commit` es el identificador inmutable; la URL es sólo locator y no
 # entra en `hash_inputs` (ADR 0013 §1). Subirlo cuando el CLI avance.
 repo   = "ssh://gitea@git.gioser.net:2345/sergio/takana.git"
-commit = "c0545ea40cbf530c9b80fc9a76a20551163574cd"
+commit = "68d052136c06b74f858a8a33d1963f45cf244fa0"
 
 [build]
 compiler = "zig-cc"