fix(word-addin): word-web recorder works end-to-end against real Word online

Verified live: this now records the full journey in real Word on the web
- new document, contract typed, manifest sideloaded, Mike pane opened,
sign-in, chat-proposed redlines applied as genuine tracked changes
(strikethrough + insertion, Accept/Reject live in the Review ribbon).

Each fix below came from live DOM recon, not guesswork:

1. EDITING CANVAS. '[contenteditable="true"]' matched Word's off-screen
   screen-reader navigation table first; the real surface is
   #WACViewPanel_EditingElement inside the WacFrame_Word_0 iframe. Typing
   also lands silently in the void while the editor is still booting, so
   the script now types INTO the canvas locator and verifies the text
   actually appears, retrying once.
2. ADD-INS DIALOG PATH. Ribbon #InsertAddInFlyout (retried - clicks are
   swallowed during ribbon init) → "More Add-ins" → the Office Add-ins
   dialog in a cross-origin iframe named "_xdm_*" → MY ADD-INS tab →
   "Manage My Add-ins" dropdown. The dropdown's visible "Upload My
   Add-in" item is a NEW element; the always-present #UploadMenuInner
   anchor stays hidden forever (a decoy locators must skip).
3. LOCALHOST TASK PANE BLOCKED SILENTLY. The pane iframe existed with
   src https://localhost:3000/taskpane.html but never issued a network
   request: Chrome's Local/Private Network Access checks block a public
   origin (word-edit.officeapps.live.com) from iframing localhost -
   exactly what a sideloaded dev add-in is. The launch args now disable
   those checks for the demo profile.
4. Failures screenshot + dump every frame's labelled controls to
   fail-<step>.json before exiting non-zero, which is how each of the
   above was diagnosed.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>