chore: bump OpenClaw to v2026.3.7 and use TCP readiness probe

[AyeCL]

Summary

• bump the default Dockerfile pin from v2026.2.9 to v2026.3.7
• use the existing TCP gateway probe for startup readiness instead of HTTP GET polling
• add a regression test covering startup readiness

Why

The template currently builds an older OpenClaw release by default, which can drift from persisted config generated by newer OpenClaw installs. The wrapper also reports a false Gateway did not become ready in time on healthy boots because the TCP listener comes up before the HTTP surfaces are ready enough for the current probe. Using the existing TCP probe matches the /healthz behavior and avoids the false negative.

[lords1m]

Code review

Found 1 issue:

1. TCP connect success does not guarantee the HTTP layer is initialized — replacing the HTTP poll with probeGateway() in waitForGatewayReady may reintroduce 502 errors on cold starts

probeGateway() resolves as soon as the kernel accepts a TCP connection on the gateway port. At that point, the OpenClaw process may still be bootstrapping its HTTP router, WebSocket upgrade handler, and auth middleware. The wrapper will then call gatewayStarting resolved, begin proxying requests, and the first real requests hit a half-initialized handler — producing the same 502 / "Application failed to respond" pattern that PRs #116 and #124 specifically addressed.

clawdbot-railway-template/src/server.js

Lines 150 to 157 in d1cfb79

	async function waitForGatewayReady(opts = {}) {
	const timeoutMs = opts.timeoutMs ?? 20_000;
	const start = Date.now();
	while (Date.now() - start < timeoutMs) {
	if (await probeGateway()) return true;
	await sleep(250);
	}
	return false;

The previous HTTP poll (fetch() returning any response) was a stronger liveness signal because it required the HTTP stack to be up. The PR's stated motivation — TCP port opens before HTTP surfaces are ready — is the opposite of this risk: it means there is a window between TCP-ready and HTTP-ready during which this probe would falsely pass. Consider keeping the HTTP probe and adjusting the timeout or retry strategy instead, or adding a short sleep after TCP success before declaring ready.

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}