Integrate run-time type-checking

[vincerubinetti]

I'm imagining that in this project, compared to other projects I've worked on, we may be less confident about all the values every api endpoint/package function can possibly return. I strongly suspect we'll run into a situation at least once where we define a TS schema for what we expect a particular function to return, and forget or miss a specific edge case where something is a slightly different shape or fields are unexpectedly missing or odd values.

As such, I think we should put in run-time type-checking into the frontend, so we can catch these errors quickly and know exactly what has happened: the backend returned something different than we expected, and here's how.

This is assuming that we don't do some kind of strict type-checking or annotation on the backend, which we've discussed in #9.

Note that libraries like Zod can do double duty of defining TS schemas and run-time checking functions in essentially one shot. That is, you don't have to define e.g. both type SomeResponse = { animal: string } and a duplicate verifyHasAnimalField(response).

[vincerubinetti]

This is assuming that we don't do some kind of strict type-checking or annotation on the backend, which we've discussed in #9.

Actually even if we don't need Zod for communication with the backend, I'll still probably end up using it for something. It could be useful for things like verifying that a user has uploaded a properly structured JSON file... or using it to safely parse dates/etc with error handling.