privacy: pseudonymize the whole ULA prefix, not just its tail

Found in a real uploaded run from the phone: the server held
fda1:3fb1:ff92:6696::2662 for a DNS server. The general IPv6 path keeps the
leading two groups on purpose - for a global address that preserves the ISP
allocation, which is the useful part - but for a ULA that passes through 32 of
the 40 random bits of the global ID.

A ULA looks like the v6 RFC1918 and the instinct is to treat it the same. It is
not analogous, and the difference is the point: an RFC1918 prefix is shared by
millions of networks and identifies none of them, while a ULA global ID is
random and unique to one network by construction (RFC 4193). The prefix IS the
identifier, so it was a network fingerprint surviving redaction.

Pseudonymized as a unit now, so two addresses on one ULA subnet still share a
pseudonymous prefix - "these hosts are on one network" survives, "this is that
network" does not. RFC1918 stays readable, and the contrast is what justifies
it; a test pins both halves.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/build-status.md

@@ -893,3 +893,24 @@ it — much of a document's payload lives in `evidence`/`metrics`/`params`, whic
 `JsonObject` by design and therefore *outside* any schema. A schema-driven anonymizer would have
 less coverage there than the name-plus-shape one now does, so the schema should be built for
 validation and external tooling, not as a replacement for the classifier.
+
+### ULA prefixes are pseudonymized whole (2026-08-01)
+Spotted in a real uploaded run from the phone: the server had
+`fda1:3fb1:ff92:6696::2662` for a DNS server. The general IPv6 path preserves the leading two
+groups (deliberately — for a global address that keeps the ISP allocation, which is the
+diagnostically useful part), and for a ULA that passed through **32 of the 40 random bits** of the
+global ID.
+
+ULA looks like the v6 equivalent of RFC1918 and the instinct is to treat it the same. That
+reasoning does not carry over, and the difference is the whole point: an RFC1918 prefix is shared
+by millions of networks and identifies none of them, while a ULA global ID is random and unique to
+one network by construction (RFC 4193). The prefix *is* the identifier — it is a network
+fingerprint that was surviving redaction.
+
+Now pseudonymized as a unit, so two addresses on the same ULA subnet still land on the same
+pseudonymous prefix: "these hosts are on one network" survives, "this is *that* network" does not.
+Three tests, one of which uses the exact value observed on the wire.
+
+Worth recording as a reasoning trap: I had originally raised this as "ULA should probably be kept
+verbatim, like RFC1918, for consistency". The surface analogy pointed the wrong way, and the
+correct answer was the opposite.

docs/measurement-schema.md

@@ -269,7 +269,7 @@ The JSON Schema (machine-readable companion, `measurement.schema.json`, generate
 
 | type | example fields | v2 anonymizer transform |
 |---|---|---|
-| `ip4`, `ip6` | addresses, routes, hops, DNS answers | prefix-preserving pseudonymization, consistent per document; well-known/reserved ranges kept verbatim |
+| `ip4`, `ip6` | addresses, routes, hops, DNS answers | prefix-preserving pseudonymization, consistent per document; well-known/reserved ranges kept verbatim. **Exception: ULA (`fc00::/7`) has its whole prefix pseudonymized as a unit.** It resembles RFC1918 but is not analogous: a ULA global ID is 40 random bits, unique to one network by construction (RFC 4193), so the prefix *is* the identifier, whereas `192.168.0.0/16` is shared by millions of networks and identifies none. Pseudonymizing it as a unit keeps "these hosts are on one subnet" while dropping "this is that subnet". |
 | `mac`, `bssid` | wifi, arp_watch | OUI kept, NIC part pseudonymized |
 | `fqdn` | DNS names, reverse lookups | per-label pseudonyms, public-suffix kept |
 | `ssid` | wifi | pseudonym |