fix(linter): orphaned-tokens should not flag MD3 paired tokens or baseline families

[mvanhorn]

Summary

Makes the orphaned-tokens lint rule aware of MD3 token families and the MD3 baseline contract, so the three shipped examples stop emitting 33-43 false-positive warnings each.

Why this matters

Per #46:

The orphaned-tokens rule fires on every MD3 semantic color token (surface-*, on-*, inverse-*, *-container, *-fixed, etc.) because they aren't referenced by any entry in components:. Result: every one of the three shipped examples (examples/atmospheric-glass, examples/paws-and-paths, examples/totality-festival) reports 33-43 false orphans.

Verified on main:

Example	Orphan findings before	After this PR
atmospheric-glass	43	0
paws-and-paths	33	0
totality-festival	38	0

The example DESIGN.md files declare the full MD3 baseline palette but the canonical components only directly reference a small slice (primary, on-primary, primary-fixed-dim, on-surface-variant). Tokens like on-primary, primary-container, inverse-primary aren't decoration — they're part of the same semantic family that consumers use at runtime. The rule was treating "no component direct reference" as "orphaned", which produces noise on every shipped example.

Changes

packages/cli/src/linter/linter/rules/orphaned-tokens.ts:

1. New colorFamily(name) helper that reduces an MD3 token name to its family root by stripping prefixes (on-, inverse-) and suffixes (-container*, -fixed*, -dim, -bright, -tint, -variant). Custom tokens that don't match the patterns collapse to themselves, so brand-blue keeps getting flagged when unused.
2. Family-aware reference tracking: when a component references one token (say colors.primary), every sibling in the same family (on-primary, primary-container, on-primary-container, primary-fixed, primary-fixed-dim, on-primary-fixed, on-primary-fixed-variant, inverse-primary) is treated as part of the in-use group.
3. MD3 baseline families exempt: the standard MD3 set (primary, secondary, tertiary, error, surface, background, outline) is part of the contract a design system ships, not optional decoration. Tokens belonging to those families don't get flagged even when no component references them yet.

packages/cli/src/linter/linter/rules/orphaned-tokens.test.ts:

• Adds 4 new test cases covering: MD3 paired tokens via referenced family, surface family with sibling reference, custom tokens still getting flagged, MD3 baseline families exempt without any reference.

Testing

• bun test src/linter/linter/rules/orphaned-tokens.test.ts — 6 pass, 0 fail.
• bun test (full suite) — 207 pass, 0 fail (was 206 before; +1 net new test that consolidated; full run added 4 new tests as above).
• bun run src/index.ts lint examples/<each>/DESIGN.md confirms the orphan count drops to 0 on all three shipped examples.

The rule still flags genuinely-orphaned custom tokens (regression test asserts brand-blue still fires when defined but unreferenced).

Fixes #46

This contribution was developed with AI assistance.

[davideast]

Thank you @mvanhorn! I'll get this merged in real quick to silence the annoying errors. This has me thinking about providing different configurations for linting depending on a specific system being followed. This would be opt-in and extensible. Let me know if you have any thoughts.