And: reduce all the possible state combinations to a FSM

Per design review, this component needed a bunch more
interactivity. Most critically, around displaying and responding
to a load error.

Rather than set a bunch of flags and toggle various elements
based on a collection of booleans, I think it's much easier to
reason about this component if it has a Finite State Machine
representing its possible states and transitions between them.

The two notable logic additions here are a rudimentary FSM
(`transition`) and a state checker (`is`).

`transition` defines all the ways the component can go from
one state to another. If a transition is attempted that doesn't
match one of these declared transitions, it does nothing.
Every transition always results in a declared state.
these two things combined make it much easier to reason
about what the component should look like at any given
moment.

Other than the state machine (which should be replaced with
something like @xstate/fsm), the rest of these changes are
text changes from UX/technical writing review.