handle starting and ending whitespace in song regex

[riknoll]

fixes the issue reported here and here

the issue here is that somehow some newlines are getting inserted into the hex literals we generate for songs. i don't know if the users did this, or maybe we have some logic in our formatter that tries to format images, but in any case the easiest fix is to just handle it in the regex here.

not sure why people are reporting this now, because AFAIK nothing related to this was changed by the recent release at all. still, should probably hotfix this.

[Copilot]

Pull request overview

This PR hotfixes song literal parsing in the Blockly music editor field so that song hex\...`` template literals can be recognized even when formatting introduces extra whitespace/newlines at the start/end of the literal contents.

Changes:

• Relax the hex\...`` parsing regex in the music editor field to allow whitespace immediately inside the backticks.

Comments suppressed due to low confidence (1)

pxtblocks/fields/field_musiceditor.ts:45

• This change adjusts parsing behavior for song hex literals but doesn’t appear to add coverage to ensure decompilation/block loading succeeds for hex template literals that include leading/trailing (and potentially embedded) whitespace/newlines. Please add a regression test (likely under tests/decompile-test/cases/) that round-trips a multiline hex song literal back into blocks without producing a grey/invalid field.

            const match = /^\s*hex\s*`\s*([a-fA-F0-9]+)\s*`\s*(?:;?)\s*$/.exec(text);

            if (match) {
                song = pxt.assets.music.decodeSongFromHex(match[1]);