fix: add reusable inverse surface semantics for tooltips

[artiphishle]

Summary

Fixes the unreadable Tooltip contrast reported in #60 by introducing a reusable, mode-aware inverse surface/content semantic pair in Surface.

What changed

• adds theme.semantics.surface.inverse as a first-class reusable semantic token
• redefines global theme.semantics.content.inverse as the paired neutral foreground for the inverse surface
• keeps role-specific inverse content unchanged: Text with an explicit semantic color still resolves that role's onSolidText
• updates Tooltip to use theme.semantics.surface.inverse instead of repurposing neutral.text as a background
• adds light/dark and brand-independence regression coverage
• adds a patch Changeset

Result

The centralized pair is:

• light mode: dark neutral inverse surface + light neutral inverse content
• dark mode: light neutral inverse surface + dark neutral inverse content

This is intentionally not Tooltip-specific. Any Surface/ZORA component or pattern can reuse the same inverse semantics.

Root cause

Tooltip previously combined:

• background: theme.semantics.neutral.text
• foreground: global theme.semantics.content.inverse

But global content.inverse was aliased to brand.onSolidText, which is calculated for brand.base, not for a neutral tooltip background. The foreground and background therefore had no guaranteed contrast relationship and Tooltip readability could depend on the configured primary color.

Validation

Added pure Bun regression tests covering:

• light inverse surface/content pairing
• dark inverse surface/content pairing
• global inverse content remaining neutral rather than following brand.onSolidText

Local execution was not available in the current agent environment because the GitHub CLI is absent and outbound network access prevented cloning/installing the repository. Repository CI should provide the executable validation for the pushed branch.

Closes #60