#15791: Docker: load buildx image and reuse gateway token

This PR fixes Docker setup failures when Buildx uses the `docker-container` driver and the built image is not loaded into the local Docker image store. Also adds a safety fallback: if `buildx --load` is available but fails in the local environment, setup automatically retries with plain docker build instead of aborting. Without `--load`, `docker compose run` may fail with: `✘ openclaw-cli Error pull access denied for openclaw, repository does not exist or may require 'docker login': denied: requested access to the resource is denied` ## Summary - use `docker buildx build --load` (when Buildx is available) so `openclaw:local` is usable by `docker compose run` - prevent gateway token drift by reusing `~/.openclaw/openclaw.json` token when present - keep existing fallback token generation behavior when no configured token exists ## Why - Buildx with `docker-container` driver can complete builds but keep output only in build cache unless explicitly loaded/pushed. - Re-running `docker-setup.sh` could generate a new token in `.env`, diverging from configured token and causing auth/pairing failures. ## Validation - `bash -n docker-setup.sh` - manual verification of token-source selection and Buildx output mode handling <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This change updates `docker-setup.sh` to (1) prefer `docker buildx build --load` when Buildx is available so `openclaw:local` is present in the local image store for `docker compose run`, and (2) reuse an existing gateway token from `~/.openclaw/openclaw.json` when `OPENCLAW_GATEWAY_TOKEN` isn’t already set, reducing token drift between config and `.env`. The script still writes the chosen token into `.env` via `upsert_env`, and then uses Compose to run interactive onboarding and start the gateway container. <h3>Confidence Score: 3/5</h3> - Moderately safe to merge, but a couple of environment-dependent failures are possible - The PR is small and focused, but it introduces additional reliance on `python3` in a script that already tries to support minimal environments, and the buildx switch is based on presence rather than capability/success. These can cause setup failures on systems where the previous behavior worked. - docker-setup.sh _{Last reviewed commit: c04c153} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->