Update docs to use lowercase statuses (#600)

docs/pages/concepts/backend-lifecycle.mdx

@@ -5,20 +5,20 @@ and defines Plane’s responsibilities at each stage.
 
 The statuses are:
 
-- `Scheduled`: The Plane controller has chosen a drone to run the backend.
-- `Loading`: The drone has acknowledged the backend and is loading the appropriate image from the registry.
-- `Starting`: The drone has loaded the image and is starting the container.
-- `Waiting`: The container has started. The drone is waiting for it to listen on an HTTP port.
-- `Ready`: The container is listening on an HTTP port. The drone is ready to route traffic to it.
-- `Terminating`: The drone has sent a request to terminate the backend. If the request was a “soft” request,
+- `scheduled`: The Plane controller has chosen a drone to run the backend.
+- `loading`: The drone has acknowledged the backend and is loading the appropriate image from the registry.
+- `starting`: The drone has loaded the image and is starting the container.
+- `waiting`: The container has started. The drone is waiting for it to listen on an HTTP port.
+- `ready`: The container is listening on an HTTP port. The drone is ready to route traffic to it.
+- `terminating`: The drone has sent a request to terminate the backend. If the request was a “soft” request,
   the backend may remain in this state for a grace period (by default 10 seoconds) before being hard-terminated.
-- `Terminated`: The drone has terminated the backend. This is considered the only terminal state.
+- `terminated`: The drone has terminated the backend. This is considered the only terminal state.
 
 A backend may skip over some of these statuses, but will only transition to statuses lower in the list, never
-higher. Every backend will eventually reach the `Terminated` state unless the drone responsible for it is
+higher. Every backend will eventually reach the `terminated` state unless the drone responsible for it is
 permanently lost.
 
-Aside from assigning the initial `Scheduled` status, the drone to which a backend is assigned is responsible for
+Aside from assigning the initial `scheduled` status, the drone to which a backend is assigned is responsible for
 reporting all status changes.
 
 Statuses returned from the [status API](../plane-api.mdx#status-api) are returned as strings matching the

docs/pages/developing/keys.mdx

@@ -17,11 +17,11 @@ Tags are useful for sharing a key space between non-interchangeable backends. Fo
 
 Every backend has an associated key. If one is not provided when calling `connect`, Plane will generate one at random. This key is returned as part of the `connect` response.
 
-Plane attempts to guarantee that if a backend is in the `Starting`, `Waiting`, or `Ready` state, the drone running the backend holds the key. It also attempts to guarantee that if a backend is in the `Terminating` state, the key may be expired but is within a termination grace period (N.B. this is unrelated to the idle backend grace period).
+Plane attempts to guarantee that if a backend is in the `starting`, `waiting`, or `ready` state, the drone running the backend holds the key. It also attempts to guarantee that if a backend is in the `terminating` state, the key may be expired but is within a termination grace period (N.B. this is unrelated to the idle backend grace period).
 
 If the drone *can't* renew the key, the drone is responsible for terminating the backend on a fixed timeline. The drone will first attempt to shut down the backend gracefully, but will then terminate it with a hard deadline.
 
-The current implementation also happens to ensure that the key is held during the `Loading` state, but this is not guaranteed to be the case in the future (this is to accomedate potential “pre-warming” behavior in a future release).
+The current implementation also happens to ensure that the key is held during the `loading` state, but this is not guaranteed to be the case in the future (this is to accomedate potential “pre-warming” behavior in a future release).
 
 ## Key acquisition and renewal
 

docs/pages/plane-api.mdx

@@ -155,7 +155,7 @@ Where `:cluster` is the name of the cluster the backend is running on, and `:bac
 
 The response is a JSON object with the following fields:
 
-- `status`: The status of the backend, such as `Ready`. See [backend lifecycle](concepts/backend-lifecycle.mdx)
+- `status`: The status of the backend, such as `ready`. See [backend lifecycle](concepts/backend-lifecycle.mdx)
   for a list of possible values.
 - `time`: The time at which the backend entered its current status, in milliseconds since the Unix epoch.
 

docs/pages/quickstart-guide.mdx

@@ -83,10 +83,10 @@ a URL that routes to that backend. The third line tells you a URL that you can u
 as JSON.
 
 Below that output, it will show a running list of states and the time they were entered. The first
-time you run a particular image, it may spend some time in the `Loading` state, because it will download the container
+time you run a particular image, it may spend some time in the `loading` state, because it will download the container
 image if it does not have it cached.
 
-Once the image is in the `Ready` state, you can open the URL provided in your browser to open the game.
+Once the image is in the `ready` state, you can open the URL provided in your browser to open the game.
 
 ## Docker Compose Configuration