Gateway-start plugin-id migration skips the bare `plugins.entries.clawrouter` that `plugins install` actually writes

[twzrd-sol]

Since #313 the gateway-start plugin-id migration is gated on BlockRun-owned config
fields. That gate never matches the config an ordinary pre-rename install actually
has on disk, so those users are not migrated on the npm update -g + restart path.

The two paths prove ownership differently

clawrouter setup proves it from disk (src/cli.ts:710-730):

const legacyPackagePath = join(homedir(), ".openclaw", "extensions", "clawrouter", "package.json");
...
legacyBlockRunInstall = legacyPackage.name === "@blockrun/clawrouter";

The gateway-start path proves it only from config fields (src/index.ts:413-419):

const legacyBlockRunInstall = Boolean(
  legacyEntry &&
    (["walletKey", "routing"]).some(
      (key) => key in legacyEntry || (legacyEntryConfig ? key in legacyEntryConfig : false),
    ),
);

Why the config-field gate misses the common case

OpenClaw's installer commits { enabled: true } for an enabledByDefault plugin and
nothing else. That is observable today: after openclaw plugins install, the entry is
exactly "blockrun-clawrouter": { "enabled": true }. A pre-rename install therefore
carries "clawrouter": { "enabled": true } with no walletKey and no routing --
the wallet lives at ~/.openclaw/blockrun/wallet.key, not in openclaw.json, so the
fields that would prove ownership are absent unless the user hand-set them.

prepareBlockRunPluginConfig already handles a bare entry correctly once the flag is
true (src/openclaw-plugin-config.ts:61-63 copies a bare enabled boolean). The gate is
the only thing standing in front of it.

Consequences on OpenClaw 2026.8.2

Verified end to end against a real openclaw@2026.8.2 in an isolated HOME, on v0.12.267:

• Legacy { enabled: true }: config ends as
  {"clawrouter":{"enabled":true},"blockrun-clawrouter":{"enabled":true}}. The stale key
  now explicitly enables OpenClaw's bundled router, a product the user never configured.
• Legacy { enabled: false } (a pre-rename opt-out): config ends as
  {"clawrouter":{"enabled":false},"blockrun-clawrouter":{"enabled":true}}. The opt-out
  is inverted -- it disables OpenClaw's bundled router while BlockRun is enabled by the
  installer default, and the proxy comes up on a machine where the user had turned it off.

Coexistence itself is unaffected: the bundled router keeps id clawrouter, BlockRun is
blockrun-clawrouter, the blockrun provider registers and the proxy serves. This is
only about the stale key.

Suggested direction

Have the gateway-start path consult the same on-disk proof clawrouter setup already
uses. A legacy ~/.openclaw/extensions/clawrouter/package.json naming
@blockrun/clawrouter is unambiguous evidence in a way config fields are not, and it
does not widen the heuristic that #313 deliberately narrowed.

Happy to send the change if you want it as a PR rather than an issue.