#9460: fix(gateway): clean up lock file on service stop

## Problem Running `openclaw gateway stop` then `openclaw gateway run` fails with: The lock file persists after service stop, causing stale PID detection. ## Solution Delete the gateway lock file in `runDaemonStop()` after stopping the service. ## Changes - `src/infra/gateway-lock.ts`: Export `resolveGatewayLockPath()` for reuse - `src/cli/daemon-cli/lifecycle.ts`: Delete lock file after service stop Fixes #9434 <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR fixes a stale gateway lock scenario by exporting `resolveGatewayLockPath()` from `src/infra/gateway-lock.ts` and using it in `runDaemonStop()` to delete the lock file after stopping the gateway service. It also adds user-facing warnings when URLs include the gateway token (dashboard/onboarding), and updates `withTimeout()` to treat AbortErrors as a fallback condition (with new unit tests). <h3>Confidence Score: 3/5</h3> - This PR is close to safe but needs a stop/lock ordering fix to avoid concurrency issues. - The lock-file cleanup addresses a real usability issue, but removing the lock immediately after `service.stop()` can reintroduce a race where a second gateway instance starts before the service has fully exited. The rest of the changes are straightforward and covered by tests for the timeout behavior. - src/cli/daemon-cli/lifecycle.ts <!-- greptile_other_comments_section --> <!-- /greptile_comment -->