[pintu544]

Fixes #570

Problem

toHaveStyle() could never match the aspect-ratio CSS property. jsdom does not implement aspect-ratio (its cssstyle dependency has a fixed property list), so it silently drops the declaration — both when parsing the style attribute and in computed styles: getComputedStyle(el)['aspect-ratio'] is undefined and getPropertyValue('aspect-ratio') is ''. The expected side parses fine, so the failure was purely on the received side in isSubset.

Fix

Added a guarded fallback in isSubset: when the computed style doesn't know a property at all (computedStyle[name] === undefined && getPropertyValue(name) === ''), the matcher compares against the element's own style declaration instead. The guard preserves existing semantics for known properties (e.g. !important corner cases). New helpers:

• getOwnStyleValue() — reads dash-case/camelCase spellings from element.style, then from the parsed raw style attribute
• parseInlineStyle() — safely parses the raw style attribute (never throws)

This also covers the React case (style={{aspectRatio}}), which sets the property via direct expando assignment.

Tests

• 2 new tests in src/__tests__/to-have-style.js: aspect-ratio via style attribute (string + object forms, incl. negative wrong-value cases) and via direct style assignment (dash-case + camelCase keys)
• to-have-style suite: 15/15 pass (13 existing + 2 new)
• Full suite: no new failures (94 pre-existing snapshot failures in 14 unrelated suites, verified byte-identical on the clean tree)
• ESLint clean on changed files