Sure, you can solve this one particular thing with fixed hardware [0]. The problem is that just slightly more complex, any designer isn't going to opt for hardcoded logic but rather going to go "we have a microcontroller sitting right here, of course we're going to use it". This path ends with firmware "security" that prevents straightforwardly reading/writing these devices, which is exactly what my comment is about.

> you're trying to derail conversation and argue in favor of weakening device security

No, I'm arguing in favor of analyzing security in terms of device owners rather than manufacturers. "Security" isn't simply some singular property, but is rather in the context of a specific party [1]. It's certainly possible to build hardware that verifies running software and also doesn't privilege the manufacturer with an all-access pass. Just no manufacturers have done it, because centralizing control in their favor is easier.

[0] even this case is borderline. Your series LED suggestion isn't likely to be work because it will drop at least 1.6v, and constrain the current draw of the camera. Also if the firmware can be reprogrammed such that it can take pictures using very low average current draw, you haven't actually solved the problem. Alternatively, an LED in parallel with the power supply will require at least an additional resistor (if not a diode and a capacitor), which costs real money in the eyes of a design engineer working at consumer volumes.

[1] eg how the TSA that drones on about "security", while they're actually making individual travelers less secure from having to unpack and splay their belongings out, making them easy targets for immediate or later theft. They're not talking about your security, they're talking about their operation's security.