feat: split no-static-styles-assignment messages

[saberzero1]

Summary

Fixes false positive where no-static-styles-assignment flagged el.setCssProps({ 'padding-bottom': 'unset' }). The rule now enforces the intended API contract: setCssProps is for CSS custom properties (--*) only, and setCssStyles is for standard CSS properties only.

Problem

The rule had a single avoidStyleAssignment message that told users "Use the setCssProps function if the CSS properties need to change dynamically.", but then flagged setCssProps itself when called with standard property names. This was contradictory: the error message recommended the exact API it was reporting on.

Additionally, setCssStyles (Case 4) had identical logic to setCssProps (Case 3); it flagged non---* keys. Since setCssStyles is the correct API for standard CSS properties, this was backwards.

Changes

New message IDs (lib/rules/noStaticStylesAssignment.ts)

• avoidNonCustomPropertyInSetCssProps: reported when setCssProps receives a standard property key. Tells the user to use setCssStyles or CSS classes instead.
• avoidCustomPropertyInSetCssStyles: reported when setCssStyles receives a --* key. Tells the user to use setCssProps instead.
• Updated avoidStyleAssignment: now mentions both setCssProps and setCssStyles as alternatives for the generic el.style.* cases.

Fixed setCssStyles logic (Case 4)

• Flipped the condition: now flags keys that start with -- (custom properties don't belong in setCssStyles) instead of keys that don't start with --.

Tests (tests/noStaticStylesAssignment.test.ts)

• Added valid cases: setCssStyles with standard property, setCssStyles with computed key
• Updated invalid setCssProps case to expect avoidNonCustomPropertyInSetCssProps
• Replaced invalid setCssStyles case: now tests { '--my-var': 'blue' } expecting avoidCustomPropertyInSetCssStyles

What changes for consumers

• el.setCssProps({ '--my-var': 'value' }) -> no error (correct usage)
• el.setCssProps({ 'color': 'blue' }) -> error with a message directing to setCssStyles or CSS classes
• el.setCssStyles({ 'color': 'blue' }) -> no error (correct usage, previously flagged)
• el.setCssStyles({ '--my-var': 'value' }) -> error with a message directing to setCssProps
• All el.style.* direct assignments -> unchanged behavior, updated message text

[liamcain]

I'm not sure that this is necessary. Isn't this already a linting error since setCssStyles expects CSSStyleDeclaration as the key

[liamcain]

This distinction isn't that significant so it's probably not really worth a custom linter rule for the setCssStyles case.