fix(ci): check-token-import workflow does not catch new token sub-keys (e.g. inputPadding.left/right)

[aweell]

Problem

The check-token-import workflow (introduced in #2731) is designed to block PRs that add new tokens without a paired mistica-web PR that updates src/skins/skin-contract.css.ts. However, it has a gap: it only catches new top-level token names, not new sub-keys on existing tokens.

Concrete example

PR #2725 adds left and right sub-keys to inputPadding across all skins:

// before
"inputPadding": { "top": { "mobile": 8, "desktop": 8 }, "bottom": { ... } }

// after
"inputPadding": { "top": { ... }, "right": { ... }, "bottom": { ... }, "left": { ... } }

The mistica-web skin contract currently declares:

// src/skins/skin-contract.css.ts
inputPadding: {top: '', bottom: ''},

So inputPadding.left and inputPadding.right are new CSS variable slots that do not exist in the contract yet. A paired mistica-web PR is required to expand the shape to {top, right, bottom, left}. Without it, the new token values are silently ignored by the generator and never become CSS variables.

PR #2725 was not blocked by the current workflow because:

1. Wrong trigger — the workflow only fires on changes to tokens/schema/skin-schema.json. PR feat(tokens): add left/right on inputPadding #2725 only modifies tokens/*.json files, so the workflow never ran.
2. Wrong detection logic — the script diffs the required array in the schema (top-level token names). Adding sub-keys to an existing token does not touch that array, so even if the workflow had run it would have reported "No new tokens detected".

Root cause

A contract update is needed whenever a new CSS variable slot is introduced. That happens in two cases:

Case	Example	Currently caught
New top-level token	Adding inputIconSize	✅ via schema required diff
New sub-key on existing token	Adding inputPadding.left	❌ not caught

Both cases produce new CSS variable slots and both require a paired mistica-web PR.

Proposed fix

1. Trigger — also fire on tokens/**/*.json changes, not only on tokens/schema/skin-schema.json.
2. Detection logic — diff the leaf paths of token value shapes between base and PR (e.g. inputPadding.left is a new leaf path). Value-only changes (e.g. spacing 8 → 12) produce no new leaf paths and should pass through without blocking.

The cross-reference step (checking that new leaf paths appear in skin-contract.css.ts) remains the same.

Impact

Any PR that adds sub-keys to an existing spacing, padding, or similar structured token bypasses the check entirely today. PR #2725 is the first known instance.