Factor API Object Schemas More Robustly

[stevekuznetsov]

We've got a validation problem: the source for our data does not have very robust schemas in place, and the ones they do have change here and there. While we're kept in the know about changes, it would be good to find a better experience in the app for non-conformant API responses.

We do an exhaustive validation of the schema by downloading the entire dataset or reading the producing code, or both, and validating incoming data at runtime using zod since it's the simplest way to discover what fields exist in the objects we're interacting with. Just because we're not using a field today doesn't mean that a developer working on a feature in that space tomorrow needs to go on a fishing expedition to figure out the schema with which they need to work for their new feature.

The downside of this approach is that our schemas are exhaustive - and we're very opinionated even on fields we're not yet using at runtime. When our validation catches errors, it's almost exclusively in fields we do not yet consume. It would be stellar to find a maintainable way to keep two sets of validations - one for fields we're actively using, where validation errors at runtime keep us from being able to actually do our work in rendering screens, and one validation for "the kitchen sink".