Summary

What problem does this PR solve?

• Root cause: manifest channel account listing normalized raw config keys into route-safe IDs, but manifest account resolution used a different mapping contract and looked up that normalized route ID directly in the raw accounts object. A raw key like 59000514e8ad@im.bot could be listed as 59000514e8ad-im-bot but then fail to resolve before startAccount.
• This PR makes manifest account resolution use the same normalized account lookup invariant as listing, and tightens the shared lookup helper so invalid config-map candidate keys such as "constructor " cannot collapse through normalizeAccountId to default.

Why does this matter now?

• User impact: a configured external Weixin account can be dropped before startup, which prevents the channel from handling inbound or outbound messages.
• The maintainer follow-up identified one remaining shared-helper edge case after the main Weixin/session-routing fix: invalid raw account keys could still be selected as the default account through fallback normalization.

What is the intended outcome?

• Fix classification: root-cause bug fix, scoped to external channel/plugin account config resolution.
• Maintainer-ready confidence: high. The fix is covered by focused routing and read-only plugin tests, plus the existing live openclaw-weixin proof that the external account starts and reaches running state.
• Why this is root-cause fix: the resolver and lister now share one account-id mapping contract, and fallback matching only considers candidate config keys that have a valid optional canonical account ID instead of letting invalid keys silently select default.

What is intentionally out of scope?

• What did NOT change: plugin manifest format, gateway startup flow, generated metadata, provider-specific openclaw-weixin code, account ID normalization rules for route inputs, config schema, migration behavior, and permissions are unchanged.
• Related open PR / same-contract scan: this is an update to the existing PR fix(weixin): startAccount preserves session routing #93686 that already owns the focused fix for issue Bug: openclaw-weixin startAccount ???,?????????? session #93556; no replacement or competing same-contract PR is being opened.

What does success look like?

• A raw provider account key that normalizes to a route-safe ID resolves back to its original config entry.
• Invalid/prototype-like config-map keys do not resolve as default through the shared normalized lookup helper.
• Focused tests pass for the helper and the manifest/read-only plugin path.

What should reviewers focus on?

• Architecture / source-of-truth check: resolveNormalizedAccountEntry is the source-of-truth helper for normalized config-map account lookup, and manifest account resolution calls it with the optional validating normalizer for config keys.
• Patch quality notes: this is not a fallback workaround; it rejects invalid candidate keys before fallback comparison while preserving valid exact-key and route-safe ID behavior.

Linked context

Which issue does this close?

Closes #93556.

Which issues, PRs, or discussions are related?

Related #93686.

Was this requested by a maintainer or owner?

Yes. A maintainer requested tightening the shared lookup helper so invalid raw config-map keys do not collapse to default.

Real behavior proof (required for external PRs)

• Behavior or issue addressed: a live external openclaw-weixin channel account whose raw provider ID normalizes to a route-safe account ID can be loaded by the Gateway, started through the channel plugin, and reported as running instead of being dropped before startAccount.

• Real environment tested: macOS Darwin 25.5.0, Node v24.15.0, OpenClaw 2026.6.2, external @tencent-weixin/openclaw-weixin@2.4.3, isolated OpenClaw home, live QR login with Weixin.

• Exact steps or command run after this patch:

  pnpm openclaw plugins install "@tencent-weixin/openclaw-weixin@2.4.3" --force
  pnpm openclaw config set plugins.entries.openclaw-weixin.enabled true
  pnpm openclaw channels login --channel openclaw-weixin
  pnpm openclaw config set gateway.mode local
  pnpm openclaw config set gateway.port 18790
  pnpm dev gateway --port 18790
  pnpm openclaw channels status --probe
  pnpm test src/channels/plugins/read-only.test.ts src/routing/account-lookup.test.ts

• Evidence after fix (sanitized live output from the existing PR proof):

  Installed plugin: openclaw-weixin
  Restart the gateway to load plugins.
  
  已将此 OpenClaw 连接到微信。
  

  $ node scripts/run-node.mjs gateway --port 18790
  [gateway] auto-enabled plugins for this runtime without writing config:
  - openclaw-weixin configured, enabled automatically.
  [plugins] loading openclaw-weixin from <proof-home>/.openclaw/npm/projects/tencent-weixin-openclaw-weixin-.../node_modules/@tencent-weixin/openclaw-weixin/dist/index.js
  [gateway] http server listening (... plugins ...)
  [gateway] starting channels and sidecars...
  [openclaw-weixin] [<route-safe-weixin-account-id>] starting weixin provider (https://ilinkai.weixin.qq.com/...)
  [gateway] ready
  [openclaw-weixin] weixin monitor started (https://ilinkai.weixin.qq.com/..., account=<route-safe-weixin-account-id>)
  [openclaw-weixin] [weixin] no previous sync buf, starting fresh
  

  $ node scripts/run-node.mjs channels status --probe
  Checking channel status (probe)…
  Gateway reachable.
  - openclaw-weixin <route-safe-weixin-account-id>: enabled, configured, running
  

• Observed result after fix: the external Weixin manifest account is listed with the route-safe ID, resolves back to the raw configured account entry, enters provider startup, starts the Weixin monitor, and is reported by channels status --probe as enabled, configured, running; the issue-specific unable to resolve account failure before startAccount is no longer present.

• What was not tested: a fresh live Weixin login was not re-run for the small maintainer follow-up commit; the follow-up is a shared helper guard for invalid config-map candidate keys and is covered by focused regression tests below.

• Proof limitations or environment constraints: local dependency installation reports a node-llama-cpp postinstall build failure because this machine has CMake 3.18.2 while that package asks for CMake 3.19+, but the focused Vitest suites needed for this PR ran successfully from the installed workspace.

• Before evidence (optional but encouraged): the new regression test failed before the helper guard with expected { id: 'blocked' } to deeply equal undefined for resolveNormalizedAccountEntry({ "constructor ": cfg }, "default", normalizeAccountId).

Tests and validation

Which commands did you run?

• Target test file: src/routing/account-lookup.test.ts via pnpm exec vitest run src/routing/account-lookup.test.ts — pass, 8 tests.
• Target test file: src/channels/plugins/read-only.test.ts via pnpm exec vitest run src/channels/plugins/read-only.test.ts — pass, 31 tests.
• ClawSweeper local commit review — pass.

What regression coverage was added or updated?

• Scenario locked in: resolveNormalizedAccountEntry({ "constructor ": cfg }, "default", normalizeAccountId) returns undefined instead of selecting the invalid raw key as the default account.
• Existing manifest/read-only plugin tests continue to cover opaque raw provider IDs like 59000514e8ad@im.bot resolving through their route-safe account IDs.

What failed before this fix, if known?

• The new regression test failed before the fix because the shared helper returned { id: "blocked" } for the invalid "constructor " key when resolving default.
• Why this is the smallest reliable guardrail: it exercises the shared helper contract directly and keeps the manifest plugin path covered without adding provider-specific code or broader fixture churn.

If no test was added, why not?

• Not applicable; a focused regression test was added.

Risk checklist

Did user-visible behavior change? (Yes/No)

Yes, only for invalid account config keys that previously collapsed to default during normalized fallback lookup.

Did config, environment, or migration behavior change? (Yes/No)

No migration or schema change. Existing valid account keys keep the same matching behavior.

Did security, auth, secrets, network, or tool execution behavior change? (Yes/No)

Yes, the account lookup helper is stricter about invalid/prototype-like config-map keys so they cannot be selected through fallback matching.

What is the highest-risk area?

• Risk labels considered: merge-risk: compatibility, merge-risk: security-boundary, and session/account routing state.
• Risk explanation: resolveNormalizedAccountEntry is exported through plugin SDK account surfaces, so the compatibility-sensitive behavior is that invalid raw account keys which only matched through fallback normalization now stop matching.

How is that risk mitigated?

• Why acceptable: the guard uses the existing optional account-id normalizer as the validating source-of-truth for config-map candidate keys, preserves valid exact-key lookup, and preserves the route-safe opaque provider ID behavior covered by tests.
• The change does not alter the public manifest schema, account ID route normalization, gateway lifecycle, or provider-specific code.

Current review state

What is the next action?

Maintainer review after this PR update; local submit checks, focused validations, and remote exact-head CI are complete.

What is still waiting on author, maintainer, CI, or external proof?

• Waiting on author: no known author-side code, proof, or CI gap after this update.
• Waiting on maintainer: final acceptance of the exported-helper compatibility/security-boundary tradeoff.
• Waiting on CI: none at the latest checked exact head; visible remote checks are complete with no failures.

Which bot or reviewer comments were addressed?

• RF-001: ClawSweeper's exact-head CI wait is satisfied by the latest remote status: visible checks are complete with no failures.
• RF-002: The exported-helper compatibility risk is mitigated by using the existing optional account-id validity check for fallback candidates, while preserving valid exact-key and route-safe ID behavior.
• RF-003: ClawSweeper's earlier pending checks-node-compact-small-whole-2 validation state is stale because the exact-head check has completed successfully.
• RF-004: The remaining shared-helper compatibility/security-boundary choice is documented for maintainer acceptance; there is no separate narrow author repair unless maintainers prefer a localized-guard direction.
• RF-005: The checking maintainer signal is superseded by the later concrete follow-up and no longer has a separate author action.
• RF-006: sliverp's follow-up about "constructor " collapsing to default is fixed by the helper guard and regression test.
• RF-007: The author sync/comment thread is addressed by the pushed PR update; no separate code action is required beyond RF-006.
• RF-008: The latest author comment summarizes the completed fix and does not introduce a new code or proof action.