Spec v0.10 draft: pin Unicode 18.0.0 for the path tables

The author chose Unicode 18.0.0, released on 16 September 2026, over
the 17.0.0 of the design: the tables freeze with capsule format 3, so
an older version would refuse for good characters that are already
standard. Section 29.5.1 now says the Unicode version is fixed with
the format, and that moving to another needs a new format (22).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

spec/DateKeys_Protocol_Specification_v0.10.md

@@ -1181,12 +1181,14 @@ Orden de las comprobaciones de la capa 4 en la clave 5: para cada entrada, en su
 
 R3, R4, R6c y R7 usan datos fijos, no los de la plataforma:
 
-- **Unicode 17.0.0:** `UnicodeData.txt`, con la categoría general, la clase de combinación canónica y las descomposiciones canónicas; `DerivedCoreProperties.txt`, con `Default_Ignorable_Code_Point`; `CaseFolding.txt`, con sus entradas C y F; y NFD según UAX #15, con la descomposición algorítmica de Hangul.
+- **Unicode 18.0.0:** `UnicodeData.txt`, con la categoría general, la clase de combinación canónica y las descomposiciones canónicas; `DerivedCoreProperties.txt`, con `Default_Ignorable_Code_Point`; `CaseFolding.txt`, con sus entradas C y F; y NFD según UAX #15, con la descomposición algorítmica de Hangul.
 - **WindowsBestFit,** de unicode.org: los quince ficheros `bestfit874.txt`, `bestfit932.txt`, `bestfit936.txt`, `bestfit949.txt`, `bestfit950.txt`, de `bestfit1250.txt` a `bestfit1258.txt` y `bestfit1361.txt`, con la conversión de Unicode a su código de página de su sección `WCTABLE`.
 
 Una implementación MUST aplicar las tablas generadas de esos ficheros, fijados por su SHA-256 (por fijar al implementar), y MUST NOT usar las funciones de Unicode de su plataforma para estas reglas: `normalize`, `toLowerCase`, las clases `\p{…}` de las expresiones regulares, el paquete `unicode` de Go o `golang.org/x/text`. Su versión de Unicode cambia con cada motor: Go 1.26.8 trae la 15.0.0, y Node 24.9, la 16.0. La implementación de referencia genera desde esos ficheros el código de las dos implementaciones, y sus pruebas comprueban los digests.
 
-Un punto de código posterior a Unicode 17.0.0 es Cn para estas tablas: R4 lo rechaza, y el escritor lo dice con un mensaje que nombra el carácter (§62.1, regla 15).
+Un punto de código posterior a Unicode 18.0.0 es Cn para estas tablas: R4 lo rechaza, y el escritor lo dice con un mensaje que nombra el carácter (§62.1, regla 15).
+
+La versión de Unicode queda fijada con el formato 3. Pasar a otra cambiaría qué rutas se aceptan, algo que un lector de esta versión solo notaría después de pedir el release, así que exige un formato nuevo (§22).
 
 ---
 
@@ -3190,7 +3192,7 @@ head
   mtime opcional; hasta 65 535 ficheros y 16 MiB; ERR_HEAD_INVALID
 
 paths
-= R1 a R10, con tablas propias de Unicode 17.0.0 y WindowsBestFit;
+= R1 a R10, con tablas propias de Unicode 18.0.0 y WindowsBestFit;
   orden por bytes UTF-8
 
 security
@@ -3261,7 +3263,7 @@ Quedan fuera de la v0.10, como trabajo futuro que esta versión no especifica:
 9. parser fuzzing.
 10. revisión criptográfica externa.
 11. vectores de las reglas de relleno (§29.1).
-12. tablas de Unicode 17.0.0 y WindowsBestFit fijadas por su SHA-256 (§29.5.1), con sus vectores de rutas.
+12. tablas de Unicode 18.0.0 y WindowsBestFit fijadas por su SHA-256 (§29.5.1), con sus vectores de rutas.
 
 ---
 
@@ -3475,7 +3477,7 @@ La v0.10 añade el formato 3 de `.dkc`, que guarda varios ficheros con sus rutas
    - Caso: el del cambio 1. Con una versión nueva del head dentro del formato 3, un lector de esta versión pediría el release y fallaría en el paso 17, que es lo que §22 prohíbe.
    - Pruebas previstas: `format3_single`, `format3_tree`, `format3_comment_only` y `head_schema.json`.
 5. **Rutas** (§7.3, §29.5, §29.5.1).
-   - Cambio: las reglas R1 a R10, con tablas propias de Unicode 17.0.0 y WindowsBestFit.
+   - Cambio: las reglas R1 a R10, con tablas propias de WindowsBestFit y de Unicode 18.0.0, la versión vigente al congelar el formato, publicada el 16-09-2026.
    - Motivo: cualquiera puede fabricar una cápsula (§36.1). Sus rutas no deben escapar de la carpeta del lector, ni confundirse, ni colisionar al extraerlas.
    - Caso: comprobado en la máquina de desarrollo, en NTFS, «ABCDEF~1» resuelve a «ABCDEFGHIJ» (R6b). HFS+ ignora ZWNJ y ZWJ al comparar nombres, como recoge la lista de `core.protectHFS` de git (R3, R4 y R7). En Node 24.9, `"～" < "\u{1F600}"` es falso, y en UTF-8 U+FF5E va antes (R8). Go 1.26.8 trae Unicode 15.0.0 y Node 24.9 el 16.0, así que sus funciones de Unicode no coinciden (§29.5.1). 127 veces «ΐ» (U+0390) miden 254 bytes y 381 unidades UTF-16 tras NFD (R3). En WindowsBestFit, bestfit1250 lleva U+00BF («¿») a 0x3F, y bestfit874 lleva U+2665 («♥») a 0x03 y U+00A7 («§») a 0x15: si R6c rechazara cualquier carácter ASCII de R4 en una proyección, esas rutas no se podrían guardar.
    - Pruebas previstas: `paths.json`, `path_fold.json` y las mutaciones de rutas de §64.
@@ -3544,8 +3546,8 @@ Ningún objeto de formato 1 ni de formato 2 cambia de veredicto ni de código, s
 - K. Nikitin, L. Barman, W. Lueks, M. Underwood, J.-P. Hubaux, B. Ford — «Reducing Metadata Leakage from Encrypted Files and Communication with PURBs», Proceedings on Privacy Enhancing Technologies 2019(4), pp. 6–33: función de relleno Padmé (§29.1)  
   https://doi.org/10.2478/popets-2019-0056
 
-- The Unicode Standard, Version 17.0.0 — Unicode Character Database: `UnicodeData.txt`, `DerivedCoreProperties.txt` y `CaseFolding.txt` (§29.5.1)
+- The Unicode Standard, Version 18.0.0 — Unicode Character Database: `UnicodeData.txt`, `DerivedCoreProperties.txt` y `CaseFolding.txt` (§29.5.1)
-  https://www.unicode.org/Public/17.0.0/ucd/
+  https://www.unicode.org/Public/18.0.0/ucd/
 
 - UAX #15 — Unicode Normalization Forms: NFD (§29.5.1)
   https://www.unicode.org/reports/tr15/