fix: keep audio play button available while loading

[rafael226]

Fixes #3382

Summary

• keep the custom audio player's Play button enabled while audio metadata is still loading
• preserve the disabled state for actual audio errors
• add a regression test that verifies the loading Play button remains focusable and keyboard-activates playback

Tests

• npm run dev
• npx eslint src/plugins/chatview/tests/message-audio.js src/shared/texture/components/audio-player.js
• npm test -- --single-run with only the new focused test temporarily enabled: 1 SUCCESS

Note: the full Karma suite currently fails later in unrelated existing MAM/MUC tests (src/plugins/muc-views/tests/mam.js) after the new audio test has already passed.

[jcbrand]

Hi @rafael226, can you please explain the purpose of this PR?

Is it possible to play already while the player is still loading?

[rafael226]

Hi @jcbrand, yes. The purpose is to avoid blocking the user's play intent while the audio element is still loading metadata.

The PR doesn't try to force playback before the browser has enough data. It only keeps the custom Play button enabled/focusable during the loading state, so a mouse click or keyboard Enter can call audio.play(). The browser will then either start when enough data is available, or reject/handle playback according to its normal media rules.

Before this change, is_loading made the Play button disabled, so the control disappeared from the keyboard interaction path even though loading is a temporary state, not an error. The button still remains disabled for actual audio errors via has_error.

So the practical intent is: loading should show a spinner/status, but should not make the Play control unavailable.