Add deserialization_exception field for programmatic error handling

[bjester]

Summary

This allows programmatic handling of deserialization errors instead of parsing error messages

• Adds a new deserialization_exception nullable field to Store model that stores the fully-qualified exception class path when deserialization fails
• Updates existing deserialization_error field to be nullable
• Updates handling of deserialization errors to set both fields, or otherwise null both of them
• Adds tests for changes
• Removes migration tests that verified the squash migration, which now cause issues with new migrations

References

Followup to #306
Closes #315

AI Usage

Directed an AI agent to tackle the issue, iterated on its work for a loop, then did a small refactor myself. Had the AI agent add test coverage, then reviewed.

[ozer550]

I might be wrong but it seems like we are doing opposite of "skip rows that previously failed deserialization" ? Was this change in behavior intended? Also adding some tests to verify the null string change for skipping would be useful!

[ozer550]

I did a grep on places where we had "deserialization_exception" and found a place where we might need to add the execution path as well?

[bjester]

@ozer550 I've updated it to set the exception in the code you found. I also grepped and found some backend code setting to empty string. We probably didn't to set it there, but I updated the code anyway, to be have parity with deserialization_error handling.