Add the personal-data catalog and the check that keeps it true

Phase 2 of the personal-data catalog spec.

resources/privacy/catalog.toml classifies every object in the schema
(316) and inbuxa's own JMAP objects (12): each property that can hold
personal data, with its categories, and for objects that hold any,
whose data it is, where it lives, its scope and what bounds its
retention (a named setting where there is one). Twenty sources that
are no object -- the log file, exporters, webhooks, spam lookups, the
Explain cache, relays and hooks, push, legacy-use records -- carry the
same facts plus the settings that turn them on, whether the data
leaves the host, and the code that writes it. Classifications of
objects that hold data about people are from the spec's source map;
the rest are typed from the schema alone (address, IP, secret).

tools/fork/privacy-check.py fails CI when an object or inbuxa object
has no entry, when a property the schema types as an address, IP or
secret is left to its object's default, when an entry names an
object, property, setting or code path that is gone, or when it uses
a word outside the catalog's vocabulary. --unlisted prints starting
entries. strip.py's report gains "Unclassified in the privacy
catalog": objects and fields new in an import and not classified,
informational like the Enterprise flags.

Tested: 13 unit tests (tools/fork/tests): the check passes on this
tree; fails on an unclassified object, an address hidden behind a
default, a secret in a set or object reference, stale properties,
objects, settings and code paths, an unlisted inbuxa object and a
word outside the vocabulary; --unlisted's entries; and the strip
report on a synthetic import. The check and the tests run in the
fork-checks job.

tools/fork/README.md

@@ -68,6 +68,25 @@ tools/fork/notice-check.py --fix    # add it where it's missing
 Run `--fix` after resolving an upstream merge: a conflict resolved by taking
 upstream's side can drop a notice the file had.
 
+## privacy-check.py
+
+Fails when the personal-data catalog (`resources/privacy/catalog.toml`) and
+the code disagree: an object in the schema or one of inbuxa's own JMAP
+objects with no entry, a property the schema types as an address, an IP or
+a secret left to its object's default, or an entry naming an object,
+property, setting or code path that no longer exists. CI runs it beside the
+name check, with its tests (`python3 -m unittest discover -s tools/fork/tests`).
+See `docs/spec/features/personal-data-catalog.md`.
+
+```bash
+tools/fork/privacy-check.py              # exit 1 on any finding
+tools/fork/privacy-check.py --unlisted   # starting entries for what's missing
+```
+
+After an upstream import, the strip report lists what is new and unclassified
+under "Unclassified in the privacy catalog". `--unlisted` types each from the
+schema alone; read the field's description before trusting it.
+
 ## record-compat.py
 
 Records what the `*_compat` tests compare against, from the Enterprise