Here's what I got. I trimmed the file in half and the attack happened, but the movie instantly desynced. I extended the sample twice and got the same result. Checked with other desmume sound options and random noise resulted in working attack with wrong duration (and movie desync), and internal desmume sample resulted in no attack.
My preliminary conclusion.
The author does
exactly what the game expects. NDS console has a microphone, the game explicitly tells you to blow into it, then it processes the input somehow and triggers the blow attack, whose duration is apparently dependent on duration of your blow input.
Desmume does not put this peripheral input into movies. It doesn't even attach it in any way like other emulators attach save files to movies. Doesn't even flag the movie as something that requires a sound sample. What desmume does: in the menu, you select what sample to use whenever a game asks for sound input. That's all. You can change this on the fly at any time, the movie doesn't care.
So what should we do? We should respect gameplay requirements and the author's effort to follow them precisely. Maybe there's some way to trick the game by using unintended things here, but that's up to whoever discovers and abuses this.
But how do we handle this, since the movie can't possibly include this data, unless we hack the emulator? There's only one way - we host it on the site separately.
Can this set a complicated precedent? Of course it can! If a game requires us to feed it copyrighted audio, we're screwed. So all we can do here is dealing with such cases as exceptions, case-by-case.