fix: use published model runtime for inbound replies

[yuzheng14]

Summary

• opt Weixin's custom low-level reply dispatch into the Gateway-published model runtime
• add a typed helper and regression test that keep usePublishedModelRuntime: true on every inbound reply

Why

Weixin still assembles its own dispatcher and calls channelRuntime.reply.dispatchReplyFromConfig directly. OpenClaw's modern inbound pipeline supplies usePublishedModelRuntime: true automatically, but this legacy path did not.

On OpenClaw 2026.9.x, the missing flag can make an otherwise valid inbound message fail before agent dispatch with PreparedModelCatalogConfigReplacedError because the caller config is checked against the Gateway's committed model-runtime owner.

PR #307 refreshes the config snapshot for each message, which is useful for configuration correctness, but testing its current head (dcef18e) on OpenClaw 2026.9.4 still reproduced the same exception. This patch is independent and complementary: it binds the low-level dispatch to the already-published runtime, matching the behavior of the modern inbound pipeline.

Fixes #311.
Related to #307.

Verification

• npm run ci
• 30 test files passed, 459 tests passed
• formatting, lint, typecheck, unit tests, and build passed
• built and installed against OpenClaw 2026.9.4; verified a real Weixin inbound message entered the agent session and received a reply without PreparedModelCatalogConfigReplacedError

The repository's existing nine lint warnings remain unchanged.

[yuzheng14]

@zengyi1001 I noticed that 1f75c70 landed essentially the same fix as this PR, with only a small documentation difference.

Since this PR predates that commit, could you please clarify whether 1f75c70 was based on this contribution? If so, I’d appreciate keeping attribution to this PR / original contribution.

Thanks.

[zengyi1001]

@zengyi1001 I noticed that 1f75c70 landed essentially the same fix as this PR, with only a small documentation difference.

Since this PR predates that commit, could you please clarify whether 1f75c70 was based on this contribution? If so, I’d appreciate keeping attribution to this PR / original contribution.

Thanks.

Thanks for pointing this out. I looked into it carefully and confirmed that commit 1f75c70 contains essentially the same implementation as this PR, addressing issue #311.

Based on the timing and the identical approach, I believe the AI-assisted analysis and fix for issue #311 referred to and drew inspiration from the implementation in this PR.

Not merging this PR directly and failing to preserve your contribution was my mistake. I’m sorry for that.

Since the fix has already landed, merging this PR now would introduce a duplicate/conflicting change. If convenient, would you be willing to submit a small PR updating the changelog to reference this fix and explicitly acknowledge that the solution was inspired by PR #313? We would be happy to review and merge it, so your contribution is properly recorded.

Also, if convenient, could you add me on WeChat? I’d be happy to discuss this further there.

Thank you again for identifying and proposing this fix.

[yuzheng14]

Thank you for the response. I have opened PR #323 to update the CHANGELOG, with attribution in both the English and Chinese versions noting that the fix was inspired by PR #313:

#323

My WeChat ID is: qq422450117