#6588: feat(channels): add 'confirming' dmPolicy mode for owner-approved responses

## Summary Adds a new `dmPolicy: "confirming"` mode that sits between `open` and `pairing`. In this mode: - The agent **receives and processes** the message - The agent **generates a suggested response** - The response is **sent to the owner for approval** instead of directly to the sender - Only after owner approval is the response sent ## Configuration ```json { "channels": { "whatsapp": { "dmPolicy": "confirming", "confirming": { "ownerChat": "554788703000@s.whatsapp.net", "timeout": 3600, "onTimeout": "queue" } } } } ``` ## CLI Commands - `openclaw confirming list whatsapp` - List pending responses - `openclaw confirming approve whatsapp <code>` - Approve and send - `openclaw confirming edit whatsapp <code> "message"` - Approve with edit - `openclaw confirming reject whatsapp <code>` - Reject (no message sent) ## Use Case Essential for: - Personal assistants managing client communications - Small businesses wanting AI help but needing final approval - Anyone who wants to leverage AI suggestions without losing control Fixes #6262 <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR introduces a new `dmPolicy: "confirming"` flow intended to generate an AI response but route it to an owner for approval before sending to the original sender. It adds: - A new `confirming` CLI (`openclaw confirming ...`) for listing/approving/rejecting pending responses. - Config/types + zod schema support for `dmPolicy: "confirming"` and `channels.whatsapp.confirming` settings. - A simple on-disk pending-response store (`src/confirming/confirming-store.ts`) plus message builders. - WhatsApp inbound integration that creates pending responses and sends an owner notification + sender acknowledgement. In the current wiring, the confirming-mode access-control logic appears inconsistent with the intended semantics (it doesn’t reliably enable confirming mode and the allowlist check compares normalized values against un-normalized ids), so the feature may not behave as expected without follow-up fixes. <h3>Confidence Score: 2/5</h3> - This PR is not yet safe to merge because the core confirming-mode gating logic likely doesn’t behave as intended in production. - Score reduced due to a likely functional bug in WhatsApp inbound access-control that prevents `dmPolicy: "confirming"` from reliably triggering, plus an ID normalization mismatch that can block allowlisted senders. Remaining issues are smaller correctness/UX concerns around what message is stored/shown and where approved replies are sent. - src/web/inbound/access-control.ts, src/web/inbound/monitor.ts, src/cli/confirming-cli.ts <!-- greptile_other_comments_section --> <!-- /greptile_comment -->