fix(word-addin): insert the stripped prose, not raw redline scaffolding

WHY THIS MATTERS
When a chat answer contains parsed redline edits, the transcript is
careful to render `stripRedlineBlocks(msg.content)` - the prose with the
ORIGINAL:/REPLACEMENT:/REASON: blocks removed, because those blocks are
machine-facing scaffolding that drives the "Apply tracked edits" flow.
But the "Insert below cursor" / "Insert below (tracked)" buttons still
inserted the RAW `msg.content`. One click would paste something like

  ORIGINAL: The Party shall indemnify...
  REPLACEMENT: The Party will indemnify...
  REASON: plain-language style

verbatim into a legal document - exactly the internal format the UI
goes out of its way to hide. What you see should be what you insert.

WHAT IS THE STRIP/PARSE SPLIT
A redline-mode answer is one string serving two consumers:
  - parseRedlineEdits(content)  -> structured edits for the Apply flow
    (Word search + tracked replacement);
  - stripRedlineBlocks(content) -> the human prose around the blocks,
    for reading and for insertion as text.
Every code path must pick the representation matching its purpose; the
insert buttons had grabbed the un-split original by mistake.

HOW THE FIX WORKS
The render already computes exactly the right value:

  const prose =
    edits.length > 0 ? stripRedlineBlocks(msg.content) : msg.content;

The insert buttons now receive `prose` instead of `msg.content`, and
their visibility condition changes from `msg.content && isComplete` to
`prose && isComplete` - so an answer that is ALL edit blocks (empty
prose) offers only the Apply flow, instead of an insert button that
would throw "There is no text to insert" after stripping. The Apply
button intentionally keeps `msg.content`: parseRedlineEdits needs the
blocks it parses.

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