The 500ms B4-4 engine burn duration explained:

I couldn't explain why the Taser rocket flight had such a short burnout duration, but still achieved a remarkably high altitude. I decided to pursue it a bit further (actually quite a bit further) and installed OpenRocket on my PC and proceeded to model the Taser to a first-order correctness. OpenRocket presented a much longer B4-4 thrust duration than what I got from the acceleration data.

After a lot of back-and-forth with me yelling at Claude about how stupid he is, we finally came up with a reasonable explanation about what could be happening to the data -- it was missing.

Here is Claude's plot of the corrected timeline, after adding roughly 300ms after the launch was detected by the Payload:

The final piece of the puzzle was to find the intersection of the altitude slope after launch with y=0. Claude used a much more sophisticated approach (he did not like my 'eyeballing' the data.) 

I took this conjecture back to Claude Code, who is responsible for the firmware code, and asked him how this could be. After a few minutes of "noodling" he presented a list of culprits -- mostly blocking by the buzzer. I had asked for a short chirp from the buzzer when the launch was detected -- this helped with debugging early on. Also, the 5s heartbeat chirp could interfere with data sampling immediately after launch if it occurred just prior. And lastly, the ring buffer that collects 500ms of data prior to launch was causing a delay while writing to the EEPROM. These totaled to 150-300ms.

These were mostly easy fixes: Eliminate the beep at launch (no longer needed), keep the ring buffer in RAM until after landing when there is plenty of time to write it to the EEPROM, and prevent the heartbeat chirp from blocking data sampling. All of these changes were implemented (saving a bit of program memory.) All is well.