docs: state the NFC filename-normalization invariant

The code already normalizes filenames and titles to Unicode NFC
(materialize.reduce_to_id_grammar, inbox.process_inbox) because macOS/APFS
hands filenames over decomposed, which would otherwise split one visual
title into two generated filenames. The invariant was implemented but not
documented anywhere in the repo.

CLAUDE.md

@@ -170,6 +170,13 @@ and fixtures, never code.
 - Determinism is bit-exact: `ingested_at` is an explicit required argument
   (no wall-clock defaults); LF-only output; golden fixtures compared
   byte-for-byte.
+- Filenames and titles are normalized to Unicode NFC before use
+  (`materialize.reduce_to_id_grammar`, `inbox.process_inbox`): macOS/APFS
+  hands filenames over in decomposed form, so an `é` arrives as `e` +
+  combining acute. Without normalizing first, the same visual name (e.g. a
+  Norwegian slugger title like "linkedin-studio") reduces differently
+  depending on which form it arrived in, splitting one title into two
+  generated filenames.
 - No model calls anywhere in the run path.
 - Credentials only as env-var *references* resolved at runtime; never in
   manifests, logs, or frontmatter.