LCP request discovery" audit incorrectly reports "fetchpriority=high" should be applied.

### FAQ

- [x] Yes, my issue is not about [variability](https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md) or [throttling](https://github.com/GoogleChrome/lighthouse/blob/main/docs/throttling.md).
- [x] Yes, my issue is not about a specific accessibility audit (file with [axe-core](https://github.com/dequelabs/axe-core) instead).
- [x] Yes, my issue is not answered by [other FAQs](https://github.com/GoogleChrome/lighthouse#faq).

### URL

https:/example.com/anyweb

### What happened?

Hello Lighthouse Team,

I'm running a Lighthouse audit and encountering an incorrect result in the "LCP request discovery" section.

Actual Behavior: The audit fails the check "fetchpriority=high should be applied", as shown in the attached screenshot.

Expected Behavior: This check should pass, as the LCP element identified by Lighthouse already has the fetchpriority="high" attribute.

Evidence: Here is the HTML snippet for the LCP element, taken directly from the Lighthouse report:

```
HTML

```

As you can see, the fetchpriority="high" attribute is clearly present on the tag.

I suspect the audit might be incorrectly parsing the attribute, perhaps because the value is quoted ("high"). This is valid HTML, so the audit should be able to recognize it.

Thank you for looking into this.

### What did you expect?

I expect the "fetchpriority=high" should be applied check to pass.

The Lighthouse report itself shows that the LCP element already has the `fetchpriority="high"` attribute, so this audit should show a green checkmark, not a red error.

### What have you tried?

_No response_

### How were you running Lighthouse?

Chrome DevTools, PageSpeed Insights

### Lighthouse Version

13.0.1

### Chrome Version

_No response_

### Node Version

_No response_

### OS

_No response_

### Relevant log output

```sh

```