Align styles to name-only references and drop the inert style id

[nathanacurtis]

Follow-up from #278, which decided a spec token carries a token name and nothing else, with resolution handled by looking that name up in the foundations data.

Styles already work this way — but only by accident, and only halfway.

Where styles stand

Rendering resolves a text or effect style by name, looking it up in the bridge manifest to get the style key, then importing by that key. The style id the spec records is never used for this.

So styles are already the model #278 decided on. Two things are unfinished:

1. The spec still records a style id that nothing reads. It is inert on the render path, and it does not survive a round trip — a spec generated from a rendered component reports the imported style's identifier, which is a different form from the one originally written. One object ends up with two identifiers depending on which direction produced the spec.
2. Name-based resolution has never been confirmed to work for every style type. Importing by key is what makes a style resolvable in a file that does not already have it, and that requires the style's key to be available in the foundations data. This was confirmed for variables when the render-side lookup was built. It has not been checked for styles.

What resolving this looks like

• Confirm every style type exposes a usable key through the REST endpoints, so name lookup can reach a key in all cases.
• Confirm nothing downstream depends on the style id the spec currently records, then remove it.
• Make the round trip report one identifier for one style, in one direction and the other.

Why it matters

Until the id is removed, specs carry an identifier that means different things depending on how the spec was produced, and comparing a generated spec against a round-tripped one shows differences that are not real. Until the key is confirmed for every style type, a spec rendered into a fresh file may silently fail to bind styles the same way it now binds variables.

[nathanacurtis]

Context from the variables work on feat/figma-from-specs (see #278): render no longer reads $extensions.com.figma.id for anything. No code path reads that field now.

That sharpens point 1 above rather than changing it. The style id in the spec was already unused by style resolution — styles resolve by name through the styles manifest — but it is now unambiguously inert across the whole render path, so removing it has no render-side consumer to worry about. What is left to check is whether anything outside render depends on it.

Point 2 is unchanged and is the harder half: variables now resolve name → key → import, with the fetched variable id as a fallback for rendering into the source file. Styles have no equivalent fallback, so confirming a usable key exists for every style type matters more than it did, not less — for styles it is the only route.

[nathanacurtis]

Closing — no observed failure. Filed from code reading rather than a real case; the fixture evidence I cited turned out to be a local unpublished style behaving as expected. Worth refiling if a published library style ever fails to bind when rendered into a file that doesn't already have it.