release channel datastore problem

### Original assumption
Release channels (#52) are separate deployments running different versions, but share a datastore so users can easily choose which channel (alpha, beta, stable) to use at any time and their data comes with them.

### Problem
If the datastore (DynamoDB) is defined by migrations built into the code, different versions will expect different datastore schemas. Different release channels will need different schemas, which potentially means different datastores. This means user data will not easily "come with" users when they use a different channel.

### Non-solutions
* Creating a new service that provides a new layer of indirection that has a stable API across releases and knows how to provide data with the right schema
* On-demand copying and syncing of data across separate channel datastores

### Possible solutions

#### Let different channels have separate user data
We can absolve the problem and just set expectations that data does not "come with" across channels. If using channels is a matter of picking which domain, and user accounts are global, then we'd have to extend each limit and abuse protection to work across releases.

A variation of this is to ease the problem by saying alpha is a separate datastore, but beta and stable use the same datastore. This reduces the possible range of differences between schemas of the shared datastore.

#### Extend lazy migrations to support different schema "views"
If migrations support migrating down, assuming old releases have access to newer migrations (which is its own problem), then old releases can detect items newer than they recognize, migrate them down in memory, and migrate them back up when writing back. This is only that simple for simple cases.

A more complicated variation involves writing old versions as separate items and including timestamps. Then newer releases can use the latest written item, migrating them up if from an old schema. This comes with obvious extra resource overhead.