Add a cross-package warning system with severity, collection, and a suppression setting

[nathanacurtis]

Problem

Warnings from the transform engine go straight to console.warn and nowhere else. There are around 20 call sites in specs-from-figma — dropped slot constraints, unresolved component keys, ignored bindings, rotation-inflated dimensions — and none of them reach the caller as data. A warning is visible only if someone is watching a console at the moment it prints.

That has three consequences:

• CLI and plugin users miss them. Nothing surfaces a warning in command output or the plugin UI, so a spec can be generated with known fidelity loss and look clean.
• They can't be filtered. No severity, no category, no prefix convention — some sites tag [ClassName], most don't. During a catalog run the useful warning is buried in the noise of the expected ones.
• They can't be turned down. A file with a known authoring quirk re-reports it on every component, every run, with no way to acknowledge and move on.

The sibling render package already solved this for itself: figma-from-specs collects warnings, resets them per render, and returns them on the render result. The transform engine has no equivalent, so the two halves of a round trip report differently.

Solution

One warning mechanism shared across the packages, replacing bare console.warn:

• A warning type — severity, a stable category or code, a human message, and the source it concerns (component, element, or prop) so a reader can act on it.
• Collection rather than printing — warnings accumulate during a run and are returned to the caller, so the CLI can print a summary and the plugin can show them in the UI. Console output becomes one consumer among several, not the only one.
• A setting to control the level, likely an enum along the lines of ALL, ERRORS_ONLY, NONE — so a run can be turned down without editing code.
• Consistent behavior across the transform and render directions, so a round trip reports the same way in both.

Acceptance criteria

• A warning carries a severity and a stable category, not just a message string
• Warnings are returned to the caller alongside the result, not only printed
• The CLI surfaces warnings in command output
• The plugin surfaces warnings in its UI
• A setting controls which severities are emitted, including suppressing all
• The transform and render packages report through the same mechanism
• Existing console.warn call sites are migrated

Problems

• Warnings are unreachable as data — console-only, so no consumer can act on them
• No severity or category, so nothing can be filtered or counted
• Prefix convention is inconsistent across call sites
• No way to suppress a known, accepted warning
• Transform and render report differently, so a round trip is inconsistent
• A repeated warning fires per component with no deduplication across a catalog run

Impacted code

• specs-from-figma/packages/specs-from-figma/src — ~20 console.warn call sites across Component/Props, Component/Styles, Adapters/RestApi, and Runtime
• specs-from-figma/packages/figma-from-specs/src — existing warning collector (Renderer.ts, types.ts), the closest model for the shared mechanism
• specs/packages/schema — the settings enum, if the level is spec-declared
• specs/packages/cli and specs-plugin-2 — the surfaces that would display warnings

Notes

Came out of a code-only prop naming fix, where a new warning had no mechanism to hook into and had to follow an ad-hoc local convention.

---

Implementation details are tracked internally.