MWI: Document tbot wait and tbot copy-binaries

docs/pages/reference/cli/tbot.mdx

@@ -22,6 +22,9 @@ The primary commands for `tbot` are as follows:
 | `tbot init` | Initialize a certificate destination directory for writes from a separate bot user, configuring either file or POSIX ACL permissions. |
 | `tbot db` | Connects to databases using native clients and queries database information. Functions as a wrapper for `tsh`, and requires `tsh` installation. |
 | `tbot proxy` | Allows for access to Teleport resources on a cluster using TLS Routing. Functions as a wrapper for `tsh`, and requires `tsh` installation. |
+| `tbot copy-binaries` | Copies the `tbot` binary (and optionally `fdpass-teleport`) to a destination directory. |
+| `tbot keypair create` | Generates a keypair for `bound_keypair` joining. |
+| `tbot wait` | Waits for a running `tbot` instance to become ready, using its diagnostics endpoint. |
 | `tbot tpm identify` | Output identifying information related to the TPM (Trusted Platform Module) detected on the system. |
 
 ## tbot db
@@ -694,6 +697,30 @@ command supports these additional flags:
 | `--dns-san`                              | A DNS name that should be included in the SVID. Repeatable. |
 | `--ip-san`                               | An IP address that should be included in the SVID. Repeatable. |
 
+## tbot copy-binaries
+
+Copies the `tbot` binary to a destination directory, optionally including
+`fdpass-teleport`.
+
+This command may be useful for copying the `tbot` binaries from Teleport's
+distroless containers into another container, for example as part of a
+Kubernetes `initContainer`.
+
+If using the `ssh-multiplexer` service with the `fdpass-teleport` helper, the
+`--include-fdpass` flag should be used to ensure that helper binary is also
+copied. However, note that the binary must be available in the source
+environment to be copied.
+
+```code
+$ tbot copy-binaries [--include-fdpass] DESTINATION-DIR
+```
+
+### Flags
+
+| Flag              | Description |
+|-------------------|-------------|
+| `--include-fdpass` | If set, also copy `fdpass-teleport` from the same directory as the `tbot` binary. |
+
 ## tbot install systemd
 
 Generates and installs a systemd unit file for a specific tbot configuration.
@@ -765,6 +792,36 @@ Note that the Teleport Proxy Service address is required to fetch the currently
 enabled [signature suite](../deployment/signature-algorithms.mdx). No authentication takes
 place at this time.
 
+## tbot wait
+
+Waits for a running `tbot` to become ready by querying its diagnostics endpoint.
+
+A `tbot` process must have been started with the diagnostics service enabled via
+the `--diag-addr` CLI flag or `diag_addr` YAML field.
+
+The `wait` command waits indefinitely for the bot (or single service, if
+specified) to begin reporting its status, and for the bot to become healthy as
+reported by the diagnostics service's `/readyz` endpoint. It is safe to run
+before the main `tbot` process has started running and will only return when
+either the bot is ready for use, or the timeout (if specified) has elapsed.
+
+If the `--timeout` flag is specified and the bot or specific service has not
+become healthy within the time limit, the command exits with an error. If not
+specified, the command will only exit if and when the bot becomes healthy.
+
+```code
+$ tbot wait --diag-addr=127.0.0.1:1234 [<flags>]
+```
+
+### Flags
+
+| Flag         | Description |
+|--------------|-------------|
+| `--diag-addr` | The configured `--diag-addr` of a running bot, in `host:port` form. Required. |
+| `--service`  | If set, waits for only the named service to become healthy. If unset, waits for all services. |
+| `--timeout`  | An optional timeout duration string, e.g. `30s`. The command exits with an error if services are not healthy before the timeout. |
+
+
 ## Destination URIs
 
 Many `tbot start` subcommands accept destination URIs via the `--storage` and

docs/pages/reference/machine-workload-identity/diagnostics-service.mdx

@@ -119,6 +119,67 @@ performance issues.
 They will only be enabled if the `-d`/`--debug` flag is provided when starting
 `tbot`. This is known as **debug mode**.
 
+### `/wait` and `/wait/{service}`
+
+The `/wait` endpoint returns the same content as `/readyz`, but delays its
+response until the bot or service has reported its initial status, regardless of
+if it reports itself as healthy or unhealthy. As with `/readyz`, if the bot or
+service is not healthy, it responds with a 503 status code. It will delay
+potentially indefinitely waiting for the initial readiness report, so clients
+should configure a reasonable timeout if necessary.
+
+This endpoint is useful when integrating synchronously with bots to ensure
+workflows that depend on bot outputs or services are in fact ready to serve
+requests, without needing to explicitly implement a readiness checking loop in
+your own app. It can be useful in CI/CD environments, or any other situation in
+which you need to be certain `tbot` is fully initialized.
+
+The [`tbot wait`](../cli/tbot.mdx#tbot-wait) helper command makes use of this
+endpoint internally, but handles additional error cases (`tbot` not yet started,
+waits explicitly for services to become healthy). Most users should prefer the
+CLI helper when possible.
+
+```code
+$ curl -v http://127.0.0.1:3001/wait
+
+HTTP/1.1 503 Service Unavailable
+Content-Type: application/json
+
+{
+  "status": "unhealthy",
+  "services": {
+    "ca-rotation": {
+      "status": "healthy"
+    },
+    "heartbeat": {
+      "status": "healthy"
+    },
+    "identity": {
+      "status": "healthy"
+    },
+    "aws-roles-anywhere": {
+      "status": "unhealthy",
+      "reason": "access denied to perform action \"read\" on \"workload_identity\""
+    }
+  },
+  "pid": 42344
+}
+```
+
+You can also use the `/wait/{service}` endpoint to wait for a particular service
+to report its initial status.
+
+```code
+$ curl -v http://127.0.0.1:3001/wait/aws-roles-anywhere
+
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+{
+  "status": "healthy"
+}
+```
+
 ## Prometheus metrics
 
 The `tbot` process exposes a number of Prometheus metrics via the `/metrics`