Fase 3: content_hash post-mutación + de-dup idempotente en el diario

El campo content_hash (ya existía en MutationEvent) ahora se puebla y se
usa para no ensuciar el diario con reescrituras sin cambios.

hammer-journal:
- content_hash_of(bytes) / hash_file(path): blake3 plano (estilo b3sum,
  "b3:<hex>"), distinto del of_inputs de artefactos — aquí la pregunta es
  "¿cambió el archivo?".
- last_for_path(path): último evento de un path.
- record_dedup(ev): omite el evento si deja el archivo idéntico al último
  estado de ese path (content_hash igual) o si es un Delete sobre algo ya
  borrado. Devuelve si escribió o no. +7 tests.

hammerd watcher: hashea cada CLOSE_WRITE y usa record_dedup; una
reescritura idéntica ni registra ni emite Modified al bus.

22 binarios de test verdes, sin warnings nuevos.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/10-roadmap.md

@@ -55,7 +55,12 @@ pre-requisito de validación.
 - [x] `hammer journal [--tail N] [--follow] [--format pretty|json]`.
 - [x] `hammer commit` registra cada archivo promocionado vía `commit_with_journal`.
 - [ ] Refinar op del watcher (Create vs Replace vs Edit con FAN_REPORT_DFID_NAME).
-- [ ] Hash del contenido tras la mutación (`content_hash`) y de-dup idempotente.
+- [x] Hash del contenido tras la mutación (`content_hash`) y de-dup idempotente.
+      `hammer_journal::content_hash_of`/`hash_file` (blake3 plano, estilo `b3sum`, distinto del
+      `of_inputs` de artefactos). `Journal::record_dedup` omite el evento si deja el archivo
+      idéntico al último de ese path (o un `Delete` sobre algo ya borrado); `last_for_path` lo
+      resuelve. El watcher hashea cada `CLOSE_WRITE` y usa `record_dedup`: una reescritura sin
+      cambios ni ensucia el diario ni despierta el bus.
 
 ### Fase 4 — Formato y flujo `.swm`  ▶ *en progreso*
 - [x] `Swm` de/serialización YAML estable (roundtrip).