Possibly a faulty buffer. Ssems common recently. Mine sticks ever so often. Ive found that its important that both ptfe tube go straight into the buffer without rubbing on the sides. Especially the outgoing side with the spring.
I had a similar issue, but in my case, the typical alert of not being able to unload the filament resulted in the AMS blinking red leads. My problem was solved whilst checking the cause (not sure if it was in the buffer or the cable)
Anyway, the important is that I lost the filament info and, thus, calibration. Until you finish the print, it isn’t possible to edit the filament PA advance value.
I tried to continue the print, but after a few layers, I cancelled as the quality wasn’t acceptable. Likely, the loss of the filament pressure advance values isn’t recoverable and was the cause of the print failure, but I cannot be sure. i.e. if the value is passed to the g-code at the print beginning, there shouldn’t be any failure.
So the filament info seems to be stored in the printer when it is sent over. It continued fine once I took everything apart and solved the jamming. Its just a matter of it not communicating that info back to the apps it seems.
The filament PA (or k value) is surely stored in the printer if you use the BL calibration tool.
I suppose it may include a sort of post-processing script which adds the PA value to the gcode. I am clueless about at which stage it adds to the gcode and if it overwrites any previous values.
In my case, it was multicoloured, if that matters at all. But it is also likewise that the print quality drop relates to the cool down during the troubleshooting, which is also supported by your findings.