fix: add execCommand fallback for contenteditable input

[voidborne-d]

Problem

When Page Agent tries to type into contenteditable elements (e.g. LinkedIn post editor, #168), the synthetic event approach (Plan A) fires beforeinput/input events and sets innerText, but some editors' internal state doesn't update — the text appears momentarily then gets wiped, or never appears at all.

This happens because editors like LinkedIn's use framework-level event handlers that don't respond to synthetic InputEvent dispatches.

Solution

After executing Plan A, we now verify the text was actually inserted by checking element.innerText. If it wasn't, we automatically fall back to Plan B: execCommand.

The fallback:

1. Focuses the element
2. Uses Selection/Range API to select all content
3. Deletes existing content via execCommand('delete')
4. Inserts new text via execCommand('insertText')

Why this works

execCommand is deprecated but still widely supported by all major browsers. More importantly, it integrates natively with the browser's editing machinery — rich-text editors built on contenteditable (LinkedIn, Quill, Slate.js, ProseMirror) all respond to it correctly because it flows through the same code path as real user input.

What stays the same

• Plan A (synthetic events) is still tried first — it works well for React contenteditable and simpler editors
• The change/blur event dispatch is unchanged
• No behavior change for <input> or <textarea> elements

Fixes #168

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}