Decide the shape axis's DENSITY SCALE — what padding / height tokens exist, so the own-box escapes have somewhere to go

Repo: motir-core. One PR — a docs-only diff (CLAUDE.md + the decision record), so it branches docs/MOTIR-<id>-<slug> and CI skips E2E.

The first subtask of MOTIR-2335, and the thing that unblocks every other one. Decide what the own-box padding / height token vocabulary IS. No component is edited here.

The question

Today each surface role owns exactly ONE padding pair and ONE height: --spacing-card-padding: 24px, --spacing-control-x/y: 10px/6px, --height-control: 36px, --spacing-chip-x/y: 10px/2px, and so on (packages/design-system/theme.css:198-223). The shipped components use a SCALE against every one of them — measured on origin/main, --radius-card surfaces pad at 12px 61 times and at the token's 24px 5 times; --radius-control surfaces pad at seven distinct values from 2px to 16px. The full table is in MOTIR-2335's body.

So "route it to the token CLAUDE.md maps its surface to" has no correct answer for 140 of 145 card surfaces. Decide which way that resolves, and say so in the tables the next reader will follow:

1. A density SCALE per role — --spacing-card-padding-sm / -xs beside the existing one, --spacing-control-x-sm, --height-control-sm, each carried by all ten [data-style] blocks. Preserves today's rendering exactly; grows the token count and asks each site to pick a step.
2. A shared density RAMP — one --density-{0..5} ladder every role's own-box padding indexes into, roles keeping only their DEFAULT step. Fewer tokens, one knob a style flips; needs a rule for which step each surface takes.
3. Collapse to the existing tokens and accept the re-pad — the current tables taken literally. Cheapest in tokens, and a visual redesign of the whole app: name it as that, with a design subtask, or reject it.
4. Narrow the RULE instead — declare own-box padding/height in scope for INTERACTIVE controls only (button / input / row / icon button / chip / tooltip / kbd — the roles that already have a token), and container padding explicitly layout. Smallest sweep; needs CLAUDE.md's tables amended to say so, or the rule keeps claiming more than the guard enforces.

Check rung 1 before deciding — how a design system that ships a density switch (Radix Themes' scaling, Ant Design's size, Primer's --base-size-*) actually exposes this — and cite what you find rather than asserting it.

Acceptance criteria

• The decision record names the chosen option, the rung-1 evidence for it (the actual token shape each mirror system ships, quoted), and why each rejected option was rejected.
• motir-core/CLAUDE.md's "Padding · sizing · elevation — by surface" table lists every token the sweep may route to after this decision — so the table and the guard can agree.
• The record states explicitly, in one sentence each, which own-box values are IN scope for the sweep and which are layout and stay raw, in terms a mechanical guard can apply.
• If the choice adds tokens: every new token is defined in packages/design-system/theme.css's @theme block AND in all ten [data-style] blocks, and tests/theme/styleRegistry.test.ts still passes — a token absent from a style block does not flip, which is the defect this whole axis exists to remove.
• No component / route file is edited by this card, and no value any user sees changes.

Context refs

• MOTIR-2335 — the measured value distribution per role that forces this decision.
• motir-core/CLAUDE.md — the shape rule and its two by-surface tables.
• packages/design-system/theme.css:198-223 (@theme padding / height) · :360+ (the ten [data-style] blocks).
• tests/theme/styleRegistry.test.ts — asserts the bare [data-style] token blocks carry no colour token; a new shape token must not break it.
• docs/styles/glassmorphism.md — the precedent for a style that needs more than the bare token block.