docs: typography hygiene + drop one in-body H1 across 5 pages

Replaced 98 typography characters (curly quotes, apostrophes, em/en
dashes, non-breaking hyphens) with ASCII equivalents per
docs/CLAUDE.md heading and content hygiene rules.

- docs/plugins/sdk-migration.md: 20 chars
- docs/help/testing.md: 20 chars
- docs/automation/tasks.md: 20 chars
- docs/plugins/sdk-channel-plugins.md: 19 chars
- docs/channels/yuanbao.md: 19 chars; removed the duplicate '# Yuanbao'
  H1 (Mintlify renders title from frontmatter).

docs/plugins/sdk-channel-plugins.md

@@ -23,13 +23,13 @@ pairing, reply threading, and outbound messaging.
 Channel plugins do not need their own send/edit/react tools. OpenClaw keeps one
 shared `message` tool in core. Your plugin owns:
 
-- **Config** — account resolution and setup wizard
-- **Security** — DM policy and allowlists
-- **Pairing** — DM approval flow
-- **Session grammar** — how provider-specific conversation ids map to base chats, thread ids, and parent fallbacks
-- **Outbound** — sending text, media, and polls to the platform
-- **Threading** — how replies are threaded
-- **Heartbeat typing** — optional typing/busy signals for heartbeat delivery targets
+- **Config** - account resolution and setup wizard
+- **Security** - DM policy and allowlists
+- **Pairing** - DM approval flow
+- **Session grammar** - how provider-specific conversation ids map to base chats, thread ids, and parent fallbacks
+- **Outbound** - sending text, media, and polls to the platform
+- **Threading** - how replies are threaded
+- **Heartbeat typing** - optional typing/busy signals for heartbeat delivery targets
 
 Core owns the shared message tool, prompt wiring, the outer session-key shape,
 generic `:thread:` bookkeeping, and dispatch.
@@ -145,11 +145,11 @@ Most channel plugins do not need approval-specific code.
 - If a channel needs native approval delivery, keep channel code focused on target normalization plus transport/presentation facts. Use `createChannelExecApprovalProfile`, `createChannelNativeOriginTargetResolver`, `createChannelApproverDmTargetResolver`, and `createApproverRestrictedNativeApprovalCapability` from `openclaw/plugin-sdk/approval-runtime`. Put the channel-specific facts behind `approvalCapability.nativeRuntime`, ideally via `createChannelApprovalNativeRuntimeAdapter(...)` or `createLazyChannelApprovalNativeRuntimeAdapter(...)`, so core can assemble the handler and own request filtering, routing, dedupe, expiry, gateway subscription, and routed-elsewhere notices. `nativeRuntime` is split into a few smaller seams:
 - `createChannelNativeOriginTargetResolver` uses the shared channel-route matcher by default for `{ to, accountId, threadId }` targets. Pass `targetsMatch` only when a channel has provider-specific equivalence rules, such as Slack timestamp prefix matching.
 - Pass `normalizeTargetForMatch` to `createChannelNativeOriginTargetResolver` when the channel needs to canonicalize provider ids before the default route matcher or a custom `targetsMatch` callback runs, while preserving the original target for delivery. Use `normalizeTarget` only when the resolved delivery target itself should be canonicalized.
-- `availability` — whether the account is configured and whether a request should be handled
-- `presentation` — map the shared approval view model into pending/resolved/expired native payloads or final actions
-- `transport` — prepare targets plus send/update/delete native approval messages
-- `interactions` — optional bind/unbind/clear-action hooks for native buttons or reactions
-- `observe` — optional delivery diagnostics hooks
+- `availability` - whether the account is configured and whether a request should be handled
+- `presentation` - map the shared approval view model into pending/resolved/expired native payloads or final actions
+- `transport` - prepare targets plus send/update/delete native approval messages
+- `interactions` - optional bind/unbind/clear-action hooks for native buttons or reactions
+- `observe` - optional delivery diagnostics hooks
 - If the channel needs runtime-owned objects such as a client, token, Bolt app, or webhook receiver, register them through `openclaw/plugin-sdk/channel-runtime-context`. The generic runtime-context registry lets core bootstrap capability-driven handlers from channel startup state without adding approval-specific wrapper glue.
 - Reach for the lower-level `createChannelApprovalHandler` or `createChannelNativeApprovalRuntime` only when the capability-driven seam is not expressive enough yet.
 - Native approval channels must route both `accountId` and `approvalKind` through those helpers. `accountId` keeps multi-account approval policy scoped to the right bot account, and `approvalKind` keeps exec vs plugin approval behavior available to the channel without hardcoded branches in core.
@@ -424,7 +424,7 @@ should use `resolveInboundMentionDecision({ facts, policy })`.
 
   <Step title="Build the channel plugin object">
     The `ChannelPlugin` interface has many optional adapter surfaces. Start with
-    the minimum — `id` and `setup` — and add adapters as you need them.
+    the minimum - `id` and `setup` - and add adapters as you need them.
 
     Create `src/channel.ts`:
 
@@ -631,7 +631,7 @@ should use `resolveInboundMentionDecision({ facts, policy })`.
           const event = parseWebhookPayload(req);
 
           // Your inbound handler dispatches the message to OpenClaw.
-          // The exact wiring depends on your platform SDK —
+          // The exact wiring depends on your platform SDK -
           // see a real example in the bundled Microsoft Teams or Google Chat plugin package.
           await handleAcmeChatInbound(api, event);
 
@@ -742,10 +742,10 @@ surface unless you are maintaining that bundled plugin family directly.
 
 ## Next steps
 
-- [Provider Plugins](/plugins/sdk-provider-plugins) — if your plugin also provides models
-- [SDK Overview](/plugins/sdk-overview) — full subpath import reference
-- [SDK Testing](/plugins/sdk-testing) — test utilities and contract tests
-- [Plugin Manifest](/plugins/manifest) — full manifest schema
+- [Provider Plugins](/plugins/sdk-provider-plugins) - if your plugin also provides models
+- [SDK Overview](/plugins/sdk-overview) - full subpath import reference
+- [SDK Testing](/plugins/sdk-testing) - test utilities and contract tests
+- [Plugin Manifest](/plugins/manifest) - full manifest schema
 
 ## Related