feat(lint): flag CSS transition as seek-unsafe

[rajanpanth]

Fixes #3493

Problem

CSS transition runs on the browser clock. A GSAP class/attr swap that relies on it looks correct in preview and --workers 1, since the browser is running continuously and the transition plays out normally. Parallel chunk workers, and snapshot --at past the settle time, restore the class on a fresh page instead, so the transition restarts from its initial state and the export flashes or shows the wrong frame.

The CSS runtime adapter only discovers animation-name, since finite @keyframes are seekable and transition is not, but hyperframes check did not flag transition itself, so nothing catches the mistake before render.

Fix

A new lint finding, css_transition_used, in the same family as non_deterministic_code and gsap_infinite_repeat:

• flags transition and every transition-* longhand (-property, -duration, -delay, -timing-function, -behavior), with or without -webkit-
• scans both <style> blocks and inline style="" attributes
• allows transition: none / transition-property: none
• ignores custom properties (--transition-speed), since the property-name regex is anchored at both ends and a custom property's name starts with --, not transition or -webkit-

Uses postcss to parse declarations, matching how repeated_id_descendant_selector elsewhere in core.ts already parses <style> blocks, rather than a hand-rolled regex over raw CSS text. That gets comment-stripping and string handling for free, and keeps a selector like .transition-card from ever being mistaken for the property (postcss separates selector from declaration, so the property-name regex only ever sees decl.prop).

Reuses the css_transition_used code name already referenced in skills/hyperframes-core/references/frame-worker-core.md, per the issue.

Testing

Eight cases in core.test.ts:

• shorthand transition in a <style> block, selector reported
• two transition-* longhands flagged as two separate findings
• -webkit-transition
• inline style="", with the element id reported
• transition: none and transition-property: none both allowed
• a --transition-speed custom property not flagged
• a .transition-card selector name, plus a commented-out transition: declaration, neither flagged

Reverting the source while keeping the tests fails exactly the four positive cases and leaves the four negative (allow) cases passing, so the tests cover the change rather than restating current behaviour.

bunx vitest run packages/lint/src passes at 507 (up from 499 with the 8 added), with the same 35 pre-existing failures in project.test.ts and snippetFragment.test.ts on a clean checkout of main, so they look unrelated to this change. oxlint and oxfmt --check are clean on both files.

[miga-heygen]

Closing — stale PR. Please reopen with a rebased version if still relevant.

[rajanpanth]

Rebased onto current main (e31ab1408) and re-checked relevance.

Still relevant: there is no rule flagging CSS transition on main, and transition remains seek-unsafe for the same reason the existing animation rules give.

This branch is still stacked on #3538 (the ffprobe commit is the parent), so it carries that change too. Happy to unstack it if you would rather take them independently.

Verification after the rebase:

• packages/lint/src/rules/core.test.ts: 85 passed.
• Mutation check: with packages/lint/src/rules/core.ts reverted to main's version and the new specs kept, exactly 4 of the 85 fail, which are the new rule's cases. The other 81 still pass, so the specs are not coupled to anything else in the file. Restored, back to 85 passing.
• My change to core.ts is purely additive (74 lines added, 0 removed), so it does not disturb the rules already there.

Worth flagging in case it bites someone else: the suite initially failed 69 of 85 for me with extractMediaSrcMutations is not a function from packages/lint/src/rules/media.ts. That was stale local state, @hyperframes/parsers was not linked into node_modules and its dist predated the export. bun install alone did not fix it; the package needed building. Nothing to do with this PR, but the failure mode looks alarming.

As on #3538, GitHub returns a 422 when I try to reopen, so I cannot reopen it myself.