mecatui: establish a stable semantic theme-token contract

Problem\n\nMecatui already loads custom palette JSON, but theme authors have raw palette keys while UI code also selects separate internal widget-style names. There is no documented, versioned semantic style contract that an extension or UI surface can safely target.\n\n## Proposal\n\nDefine and document a stable semantic token vocabulary for mecatui, initially covering text, muted, primary, secondary, accent, success, warning, error, and info. Migrate UI widget styles to resolve through that vocabulary while retaining internal layout/widget details as private implementation. Publish the token schema and compatibility policy alongside custom-theme documentation.\n\n## Acceptance direction\n\n- A custom theme can override every public semantic token through documented JSON.\n- Existing built-in themes remain visually coherent.\n- Internal widget-style names are not exposed as extension API.\n- New presentation extensions, including the planned status line, resolve colors through the same tokens.\n- The theme contract is covered by validation and compatibility tests.\n\n## Out of scope\n\n- A status-line implementation itself.\n- Terminal escape-sequence passthrough.\n- A guarantee that every current raw palette or widget-specific field becomes public API.\n\nThis is related to #745 (light mode), but is broader: it establishes the semantic contract needed by custom themes and future themed extensions.

Start by tracing mecatui's custom palette JSON handling and the UI widget-style resolution described in the issue. Define the public semantic token schema and compatibility policy, then check that built-in themes, custom themes, validation, compatibility tests, and future presentation extensions all use the documented tokens without exposing internal widget names.