#16304: fix(bluebubbles): accept webhook message fields at top level

## Summary This PR fixes the BlueBubbles webhook compatibility issue where incoming iMessage webhooks were rejected with "invalid payload" error. The fix adds a fallback in `extractMessagePayload()` to handle the case where BlueBubbles sends message fields directly at the top level of the webhook payload without a wrapper (data/payload/event/message). ## Changes - Added `looksLikeMessage()` helper function to detect if a payload looks like a BlueBubbles message - Added fallback in `extractMessagePayload()` to use the payload directly as message when no wrapper is found but payload has message-like fields - Added test case to verify the fix works with top-level message format ## Testing - All 52 existing tests pass - New test case "accepts POST requests with message fields at top level (BlueBubbles standard format)" passes - Tested by running: `npx vitest run extensions/bluebubbles/src/monitor.test.ts` Fixes openclaw/openclaw#16282 <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR fixes BlueBubbles webhook compatibility by adding support for webhooks where message fields are sent directly at the top level instead of nested within a `data` wrapper. The fix adds a fallback in `extractMessagePayload()` that uses the payload directly as a message when no wrapper is found but the payload contains message-like fields (`text`, `body`, `handle`, `sender`, `isFromMe`, `chatGuid`, or `guid`). <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - The changes are minimal and focused. The fix adds a simple fallback for detecting top-level message payloads without affecting existing wrapped format handling. The new `looksLikeMessage()` helper uses reasonable field indicators to avoid false positives. Test coverage is appropriate with a new test case verifying the fix. - No files require special attention _{Last reviewed commit: bf4982d} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->