fix(useMediaControls): better representation for "waiting" value

[ferferga]

Before submitting the PR, please make sure you do the following

• Read the Contributing Guidelines.
• Read the Pull Request Guidelines.
• Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
• Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
• Ideally, include relevant tests that fail without this PR but pass with it.

---

Description

"waiting" only fires when there's a lack of data in the middle of the playback. However, it doesn't take into account the lack of data when the source is attached to the element, as "loadeddata" does. I think it's safe to assume people want from "waiting" all possible buffering states. In the probably scarce cases where the user wants more control over the native event handlers, native event handlers can still be used.

"playing" also represents when a current playback is happening now.

---

🤖 Generated by Copilot at b092cfe

Improved media controls state handling by useMediaControls. Added support for more media events and states, such as waiting and playing.

🤖 Generated by Copilot at b092cfe

• Update useMediaControls function to handle more media events and states (link)

[emmanuelgeoffray]

@ferferga thank you for working on this !
I agree with you, we just want that 'waiting' represents all buffering state.

I'm having similar issues with waiting not returning to false. Even with your fix.
From what I debugged, clearing waiting on the seeked event, fixes the issue.
I think it is safe, but I may not know all the details behind the seeked and waiting events.

[ferferga]

@emmanuelgeoffray Can you give a playground I can test? Something with a large enough audio file would be enough I guess, given with DevTools I can mimick slow network conditions.