We should consolidate DB result parsing

[slifty]

Right now we in every endpoint we guard against the database response to ensure the database provided a valid type.

As we've implemented more endpoints (and more complex endpoints) we're increasingly duplicating those checks and, more meaningfully, duplicating the need for complicated mocks in our tests.

This came to a head in #210

It would be good to explore creating a centralized helper function that will run a database query and properly parse / handle / throw in the event of an issue. This could hopefully cut down on duplicated test coverage.

[slifty]

On this note -- we can actually use TS generics to signal what type of object is going to be returned by a given db.sql call -- however this is just a type signal and if the query is malformed it could result in a lack of type safety.

I'm inclined to prefer to have type guards since they verify the returned value's type at runtime, but wanted to raise the option in case others felt that was overkill. For instance maybe a better approach would be to protect against malformed queries is to write tests against he query specifically so the tests would fail if they are incorrect. This would potentially allow for edge cases but would result in more succinct code.

For what its worth our current type guard actually only exists to validate the response before sending it -- the fact that it happens to be a type guard is really secondary. So I guess this is more a question of: do we want our code to validate that our return value is, in fact, the documented schema before returning it.