Excellent points, as expected. I guess in this crowd where everyone seems to have be comfortable with SMT rework, I figured scopes (and related skills to set triggers, etc.) would be common, but you’re right that you need one of the affected people to have those, so it’s surely an minority of a minority. (Thanks, @alexhude !)
With this info, there are some games you can play to test the startup power crowbar theory. On successive “frames”, you can toggle even/odds (or thirds or fourths…) so that all thirty (?) LEDs aren’t powered at once. You’d still have DAT going wiggly wiggly, so if the theory is that DAT is shorted to “somewhere important” the (admittedly lower duty cycle) pin might still be dumping a signal into the bad place but fewer LEDs would be active at once so there would be less current. Humans may perceived a reduced brightness, but with a suitable refresh, probably not a flicker.
Assuming you’re lighting 8/255th’s of RGB, one so staggered sequence would be:
F0: 8(GRB) ---- 8(GRB) --- 8(GRB) --- ...
F1: --- 8(GRB) --- 8(GRB) --- 8(GRB) ...
Similarly, three LEDs per bulb is more than one LED per bulb. If you turn on just one of {RGB}, the current pulled will be lower. I don’t know if it’s reflected in the WS2812, but different colors of LEDs take different amount of current at the same voltage. ISTR that blue is the highest and red is the lowest. (Trivia: Espressif certifies designs with power indicators on GPIOs on the ESP32 in otherwise identical packages that are red, but not blue.)
Instead of white try turning on just red. The actual shape of the signal on DAT will be altered to have fewer ones per pixel, but it’ll still be at the same overall frequency. This is probably a single-byte source change.
Repeated Frames: 8(-R-) 8(-R-) 8(-R-) ...
(Something non-obvious in the markdown is making the colors show. That’s not intentional. Read this on a VT100; not a VT241 
)
Either of these attempts will alter the waveform being dumped onto DAT so depending on where that pin is being (possibly) accidentally routed, we may be changing the reaction of the thing we’re disturbing beyond just changing brightness/color/interleaving.
One thing that Alex (or others) may try under your tutelage is to either remove power (and/or DAT) from the LED strip, reducing current to zero but still emitting wigglies on DAT or externally clipping a more independent 5V supply to the LED strip, but I’ll leave that to the real EE types to decide how they feel about having potentially two independent 5V sources in the same system, hopefully in the same ground reference.
If the injected 5V makes you nervous, an alternate approach that we do All The Time in strip lighting is to power the strip from a different source than the CPU completely. Lift the +5V pin from the WS2812 strip and provide power to the strip ONLY from some other 5V source. Then if the 2812’s are hungry, they’re fed power from a different trough.
A large (by digital scale) cap on the power rails of the 2812’s might be an interesting experiment if we’re testing the power being a DOS attack on the SOC’s power. The key question that I think we have is whether we’re sagging the SOC’s power on startup or whether that DAT pin is “leaking” to someplace unintended, right?
I suppose one other variable might be the PIO code that’s presumably bit-banging the DAT line. I don’t know RP2040 well enough to debug that mentally.
P.S. It may be increasingly obvious why I want to implement a WS2812 reader logic analyzer mode for buspirate once I get one.
