The test vehicles accept test/prod signed versions
Regular vehicles only accept prod signed versions
They are otherwise identical.
The test vehicles were sent test signed versions
The prod vehicles were sent the exact same update, signed with test.
This would not be uncommon since the test vehicles probably occasionally run test releases for debugging.
Further, the update is probably multiple signed pieces, and the only part accidentally signed with test was likely infotainment software.
Or something like this.
It's hard to believe they wouldn't test sending badly signed updates, so i have to imagine it's a particularly weird badly signed update.
In other words, i would not assume they are idiots.
You could get this situation if the application code accepted signatures the bootloader does not though. I can imagine that accidentally occurring.
OTA is generally developed by tier 1, so this is probably a bug in the tier 1's code. (Samsung, Panasonic, Sony, etc are common tier 1s in this space.)
IE OTA is a signed package, inside package are also signed binaries. OTA itself is properly signed, a single binary (infotainment) is signed with wrong key.
While most OTA verifiers will verify the OTA signature (which this would pass), most don't verify the individual inside-package binary signatures at install time, only at runtime.
So, OTA update comes in, containing a bundle of software for different subsystems. It's sent to different subsystems. Then, those subsystems check integrity at startup, but one subsystem's bootloader isn't happy because the firmware looks to be invalid.
You can only prevent this if the OTA knows how to do equivalent verification for every subsystem in the car that checks integrity. (And, of course, even if you do this, there's other ways you can go wrong that aren't specific to integrity checks).
It seems silly to off the cuff assert that it is a bad process or only done by those who have no idea what they are doing.