Feat: Include data attributes in element path

[panrafal]

Enhanced getElementPath() in package/src/utils/element-identification.ts to include data-* attributes when building the readable element path.

Many applications use data-testid, data-component or similar attributes to identify components. This is very often an easily grepable static text, so it's a good candidate for element locator, contrary to minified classes and tailwind markup.

As both user and a used UI library can add their data-* attributes, we're using the first and last one - to cover {...props} splats that are done before, or after lowe-level attributes.

Behavior

• If an element has one data-* attribute, append it as [data-name="value"]
• If an element has more than one, append the first and last as [data-first="v1"][data-last="v2"]
• Elements with no data-* attributes are unchanged

[vercel]

@panrafal is attempting to deploy a commit to the Benji Taylor's Projects Team on Vercel.

A member of the Team first needs to authorize it.

[jameslcowan]

I like the idea of using data attributes as a locator hint, but I would be careful about taking arbitrary data-* pairs verbatim.

A lot of component libraries add noisy runtime attributes like data-state, data-side, data-orientation, data-level, etc. Those are often less stable and less grepable than the current class/id fallback, and elementPath gets copied straight into the output. Very long or user-content-heavy values can also bloat the path quickly.

I would probably either:

• restrict this to a small stable subset like data-testid, data-test, data-cy, data-qa, data-component
• or add some filtering around value length / obvious runtime-state attributes, with a couple of targeted tests so the path quality does not regress over time.

[panrafal]

It probably should be configurable, as it really depends on the framework and approach one is using. My first thought was to just expose it as a function to the user, as sometimes it's css classes, sometimes attributes and sometimes a combination of both. But the problem is with threading this through - just didn't want to make this PR too big.