#19644: feat(docker): add init script support via /openclaw-init.d/

## Summary - Adds a Docker ENTRYPOINT that runs user scripts from `/openclaw-init.d/` before starting the gateway - Standard Docker pattern (nginx, postgres, etc.) for customizing container startup - No change to default behavior when no init scripts are mounted ## Fix from #18450 The previous PR (#18450) was reverted because init script exit codes were silently swallowed by the `sed` pipe (POSIX `sh` has no `pipefail`). This version captures the exit code **before** piping output to `sed`: ```sh output=$("$script" 2>&1) rc=$? printf '%s\n' "$output" | sed 's/^/ /' if [ $rc -ne 0 ]; then echo "[openclaw-init] WARNING: $(basename "$script") exited with status $rc" fi ``` This properly detects and logs init script failures while still indenting output. ## Test plan - [ ] No init scripts mounted → gateway starts normally (no output from entrypoint) - [ ] Mount a dir with executable scripts → scripts run in order before gateway - [ ] Non-executable files → skipped with warning message - [ ] Init script fails → exit code detected and warning logged - [ ] `docker run openclaw echo hello` → init scripts run, then echo (exec passthrough works) 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- greptile_comment --> <h3>Greptile Summary</h3> Re-introduces Docker init script support (`/openclaw-init.d/`) that was reverted from PR #18450. The fix correctly captures init script exit codes before piping output to `sed`, resolving the original POSIX `pipefail` issue. The entrypoint follows the standard Docker pattern of running user-mounted scripts before `exec`-ing the main CMD. - The exit code capture fix (`output=$("$script" 2>&1); rc=$?`) properly addresses the reason for the revert — exit codes are no longer swallowed by the sed pipe - Init script failures are **non-fatal** (only a WARNING is logged), which diverges from the postgres/nginx patterns cited in the PR description where init failures typically abort startup via `set -e` - The `docker-compose.yml` CLI service overrides `entrypoint` entirely, so init scripts only apply to the gateway service — this is consistent with intended behavior - The `ENTRYPOINT` uses a relative path (`scripts/docker-entrypoint.sh`) which works because `WORKDIR /app` is set, though the original PR used an absolute path (`/app/scripts/docker-entrypoint.sh`) <h3>Confidence Score: 3/5</h3> - This PR is generally safe to merge but has a design decision around non-fatal init script failures that should be intentionally confirmed - The core exit-code-capture fix is correct and addresses the revert reason. The script is well-structured POSIX shell. However, the non-fatal handling of init script failures diverges from the cited postgres/nginx patterns (which use set -e and abort on failure), meaning users could have init scripts silently fail while the gateway starts in a potentially broken state. This is a design choice that should be explicitly confirmed rather than a bug. - Pay close attention to `scripts/docker-entrypoint.sh` — the non-fatal error handling on lines 26-28 is the key design decision to evaluate _{Last reviewed commit: fce976c} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->