brand-builder.html: surface 5th variant (Brand Canonical Document) + brand_refs[] editing

[bokelley]

Follow-up from PR #4505 (3.1 distributed brand.json).

What ships in 3.1

`brand.json` gains a 5th variant — Brand Canonical Document — and `brand_refs[]` on House Portfolio. See release notes and the normative spec.

What's missing in the admin UI

`server/public/brand-builder.html` is today's primary surface for creating/editing brand.json files. It exposes the four pre-3.1 variants but does not yet:

• Author Brand Canonical Documents. A sub-brand team standing up its own canonical document at its own domain has no admin path. They have to hand-edit JSON.
• Edit `brand_refs[]` on a House Portfolio. Authoring the pointer entries (`domain`, `brand_id`, optional `managed_by`, optional `effective_at`) is a typed-form surface that doesn't exist.
• Distinguish inline (`brands[]`) vs pointer (`brand_refs[]`) children. A house with mixed shape needs a UI that makes the distinction visible.
• Express the cross-array uniqueness invariant. `brand_id` MUST NOT appear in both `brands[]` and `brand_refs[]`. The builder should validate this before save.
• Render mutual-assertion status. When a house adds a `brand_refs[]` entry pointing at a leaf, the builder should be able to (best-effort) fetch the leaf's published document and confirm reciprocation, surfacing the trust state.
• Expose typed brand-level trademarks. PR feat(brand-protocol): ratify distributed brand.json + fold + typed trademarks #4505 adds `#/definitions/trademark` with `status`, `license_type`, `licensor_domain`, `countries`, `nice_classes`. The builder's trademark form needs to expose these.

Scope

Single UI surface (`server/public/brand-builder.html`) — about 159KB today. Likely needs:

• New mode/screen for Brand Canonical Document authoring (versus the existing House Portfolio mode)
• Form for `brand_refs[]` entries
• Validator hooks for cross-array uniqueness + mutual-assertion check
• Typed-form treatment of the trademark shape

Open questions

• Should the builder also handle the self-healing notification SHOULD? When the user adds a `brand_refs[]` entry pointing at a leaf that hasn't reciprocated, the builder could prompt to email the leaf-owner team. Out of scope or in scope?
• Surface the Adopting brand_refs[] migration walk-through inline as guided flow, or just rely on docs?

Related

• PR feat(brand-protocol): ratify distributed brand.json + fold + typed trademarks #4505 — protocol change that this UI work surfaces
• `server/public/brand-viewer.html` (separate issue) — needs trust-tier visualization
• Addie brand-tools (separate issue) — needs MCP tool support