Redesign the Reply Drafter prompt for varied, context-aware suggestions

[OwenMcGirr]

Problem

The Reply Drafter prompt (LlmManager.PROMPT) is generic and bakes in
assumptions that do not generalise:

Look at this screenshot of a conversation. Suggest 3 short, natural, friendly
replies the person could send next. ...

• "friendly" forces every suggestion into one tone. The Reply Drafter lands
  in all kinds of threads — coordinating plans, disagreement, emotional
  support, formal/work messages, declining something — and three cheerful
  options are unusable in most of them.
• For a switch user, unusable suggestions mean falling back to slow manual
  typing, which is exactly what the feature exists to avoid — so this is an
  accessibility gap, not just polish.
• The prompt also never tells the model which side of the conversation is the
  user's, and the requested "3" disagrees with the parser's cap of 5.

Design

Replace PROMPT with a structured rubric. Behaviour agreed:

• Auto-varied — one prompt; the model reads the conversation and returns a
  varied set. No extra taps for the user.
• Anchored but flexible — always include at least one reply that declines,
  disagrees, sets a boundary, or buys time.
• 3-5 replies, mixed length — short by default, a longer one when needed.
• Tone- and warmth-matched — match the conversation's seriousness, and its
  texting style (kisses like x/xx, emoji, pet names) so replies are not cold.

New prompt

You are helping someone reply in a conversation. The image is a screenshot of
that conversation. Think through these steps, then write only the reply options.

1. Read the conversation — its topic, tone, and how serious or casual it is.
2. The messages on the right (often a different colour) are the user's own; the
   messages on the left are from the other person. You are drafting what the
   user sends next, replying to the other person's most recent message.
3. Write 3 to 5 replies the user might realistically want to send — each in the
   user's own voice, in the same language as the conversation, and ready to
   send as-is.
4. Make the replies genuinely different from each other in stance — for example
   one that accepts or agrees, one that is neutral or asks a question, and one
   that disagrees.
5. Always include at least one reply that lets the user say no, disagree, set a
   boundary, or not commit yet — worded to fit this conversation.
6. Match the conversation's tone and seriousness. If it is tense, sad, awkward,
   or formal, keep the replies measured and appropriate — do not make them
   cheerful or upbeat.
7. Notice the conversation's warmth and texting style — kisses (x, xx), emoji,
   pet names, casual abbreviations. If the other person uses them, the replies
   may use them too, including a matching sign-off, so a reply does not come
   across as cold. Keep replies plain when the conversation is plain or formal.
8. Keep most replies short. Include a longer reply only when a brief message
   would not be enough.

Output only the replies, one per line. Keep each reply on a single line, even a
longer one. Do not add numbering, labels, preamble, or any other text.

Scope

• Single change: LlmManager.PROMPT becomes the rubric above, as a
  trimIndent() triple-quoted string.
• parseSuggestions() and MAX_SUGGESTIONS = 5 are unchanged — the prompt's
  "3-5" now agrees with the cap.

Acceptance

• ./gradlew compileDebugKotlin passes.
• On-device tuning pass: suggestions vary in stance, always include a
  decline/disagree option, match tone for casual / tense / formal / affectionate
  threads, and stay correctly formatted (one per line).