Describe the bug

shouldFallbackToStartupEntry() in src/daemon/schtasks.ts has a regex that only matches English and Spanish error messages, causing the fallback mechanism to silently fail on Chinese (and likely other non-English) Windows locales.

Steps to reproduce

1. On a Chinese Windows system (or any non-English locale)
2. Run openclaw update (or openclaw gateway install --force)
3. If schtasks /Create fails with a permission error, the localized error message (e.g. 拒绝访问) is not recognized

Expected behavior

The fallback should detect the schtasks failure and create a Startup folder shortcut instead of throwing an unhandled error.

Actual behavior

Restarting service...
Failed to refresh gateway service environment from updated install: Error: updated install refresh failed: Gateway install failed: Error: schtasks create failed: 错误: 拒绝访问。

The update itself succeeds (npm package is updated), and a separate watchdog picks up the gateway, but the service registration step fails entirely.

Root cause

function shouldFallbackToStartupEntry(params) {
    return /(?:access is denied|acceso denegado)/i.test(params.detail)
        || params.code === 124
        || /schtasks timed out/i.test(params.detail)
        || /schtasks produced no output/i.test(params.detail);
}

These locale variants are missing:

...and many more.

Suggested fix

Option A (simplest) — widen the regex to cover common locales or use a catch-all:

return /(?:access|acceso|accès|zugriff|アクセス|拒绝|拒絕|отказано|거부)/i.test(params.detail)
    || params.code === 124
    || /schtasks timed out/i.test(params.detail)
    || /schtasks produced no output/i.test(params.detail);

Option B (more robust) — check the exit code instead of parsing localized text. schtasks /Create consistently returns exit code 1 on access-denied failures regardless of locale. Could change to:

    || params.code === 1  // schtasks access denied / generic failure (locale-independent)

Option C — invert the logic: try schtasks, and on any failure, fall back to the Startup folder shortcut. The fallback is already the safe path.

Environment

• openclaw version: 2026.5.20
• OS: Windows 11 Pro (zh-CN) — 10.0.26200
• Node: (from npm global install at %APPDATA%/npm/node_modules/openclaw)

Context

This issue was masked on my system because a separate watchdog scheduled task restarts the gateway process independently. Without that watchdog, the update would leave the gateway unregistered and not auto-starting on login — the exact scenario the fallback was designed to prevent.