From the decodebin source, we can see that the caps argument passed to autoplug_continue comes from the plugin pad template. And avdec_wmav1 plugin src pad template doesn't have rate, which leads to the missing rate in autoplug_continue.
I'm not quite sure where you're getting that, but as far as I can tell, get_pad_caps() does query the current caps, not the template caps. I think CAPS queries might fall back to the template if nothing else is set, but I don't remember.
The problem seems more subtle: ffmpegauddec actually sends multiple caps events before sending any data, where the second caps event is more specific than the first. For some reason (either consistent timing, or that second caps is always sent before the video caps are fixed) this second caps is always sent before pads are exposed via pad-added, so Wine will always see the more specific caps.
This is a bit annoying—yet another case where GStreamer's "reactive" model doesn't fit the "proactive" model needed for any win32 multimedia API. It does mean that wg_parser_stream_get_codec_format() is not going to be perfectly reliable, but ultimately few things involving GStreamer are.
Probably we should have wg_parser_stream_get_codec_format() only return the format from autoplug-continue if it was actually compressed, and just alias wg_parser_stream_get_preferred_format() otherwise, to account for this.