spec: @sensitive(class) — org-defined taxonomy in, key refs out (#111, #112)

[trendvidia]

Resolves the two §6.7 deferrals as a pair (§13 rows 13/14, ledger #21 children). The deciding consumer is the planned chameleon editor with enterprise key management (plus pxfed cloud): sensitive-field maintenance controlled by key access needs a stable schema-side routing handle — which reverses the #111 deferral — while making schema-side key references more dangerous, which cements the #112 rejection.

#111 — accepted: annotation sensitive(class: string = "")

• Open, org-defined vocabulary. Sensitivity taxonomies are org policy, not cross-port interop; protection layers map class → key domain in their own configuration. No fixed enum, no spec registry. The protowire. prefix is reserved (compile-time rejection, mirroring the §7 code-namespace reservation).
• Single string, never a list — one-way door pinned deliberately: field → class → key-domain routing must be deterministic. Orgs needing intersections define composite classes.
• Effective-class rule for the §6.7 transitivity chain: nearest @sensitive that specifies a class wins (field, then alias chain most-derived first, then message); a bare @sensitive reasserts sensitivity without reclassifying — it never erases an outer class.
• Redaction minima stay class-invariant, including for "" (sensitive but unclassified — exactly today's behavior, so existing bare @sensitive schemas are untouched).
• Additive defaulted parameter riding the standard AnnotationArg carrier: no grammar production, extension number, or report change.

#112 — rejected: no @encrypted(key_ref) in the schema

Key refs, algorithms, and rotation state are deployment topology — they churn per environment/tenant while the data's meaning doesn't — and annotations lower into FileDescriptorSet artifacts that ship across org boundaries (pxfed cloud makes the leak concrete: schemas travel to the hosted service, key topology must not). Same reasoning that keeps engine config out of file options (§9.4). The sanctioned contract: schema declares what + which class; chameleon maps class → key domain in its own configuration, so rotation never touches the schema.

Changes

• proto/schema/v1/annotations.proto: annotation sensitive; → annotation sensitive(class: string = "") with the rules in the doc comment.
• docs/RFC-001-schema-extensions.md: §5.2 library listing; §6.7 classification-parameter rules (4) + protection-metadata rejection; §13 rows 13/14 resolved.
• testdata/schema-extensions/20_sensitive_class.proto: compile-only fixture pinning every arm of the effective-class rule (no golden — class never appears in reports).
• testdata/schema-extensions/invalid/reserved_sensitive_class.proto + manifest row: the reserved-prefix MUST-reject.
• CHANGELOG.md [Unreleased]: both entries.
• docs/RFC-001-issues.md: resolution records (second commit).

Verification

Compiled through reference protocompile v0.19.0 (same pipeline as the internal/schemaext harness): updated annotations.proto clean; 16_sensitive_golden (bare @sensitive) clean — the defaulted param keeps existing use sites arity-valid; 20_sensitive_class.proto clean. The invalid fixture currently compiles — protocompile does not yet enforce the reserved prefix; gap issue to be filed on protocompile (precedent: protocompile#121).

Closes #111. Closes #112.