[Bug]: SendBox can lose submitted prompt when onSend rejects

[zodd7]

Summary

The SendBox currently clears the composer immediately before awaiting onSend(). If onSend() resolves with false, the submitted prompt is restored. However, if onSend() rejects, the rejection path is swallowed and the submitted prompt is not restored.

This creates a prompt-loss path for asynchronous send failures, which is especially painful for long coding prompts or detailed task instructions.

Current behavior

Current SendBox flow on main is effectively:

setInput('');

onSend(finalMessage)
  .then((result) => {
    if (result === false) {
      setInput(finalMessage);
    }
  })
  .catch(() => {})
  .finally(() => {
    setIsLoading(false);
  });

So there are three materially different outcomes:

Outcome	Current result
onSend() succeeds	Composer remains cleared
onSend() resolves false	Submitted prompt is restored
onSend() rejects	Error is swallowed; submitted prompt can be lost

Expected behavior

A failed send should never silently destroy user-authored input.

• Successful send: composer stays cleared.
• onSend() returning false: existing restoration behavior remains.
• onSend() rejecting: submitted prompt remains recoverable.
• A delayed failure must not overwrite newer text the user typed after initiating the send.

Proposed implementation direction

Keep the existing optimistic clear behavior, but make failed-send recovery race-safe.

Track whether the composer has changed since the submitted message was cleared. On rejection:

1. restore finalMessage when the composer is still in the post-send empty state;
2. do not overwrite newer user input;
3. preserve the existing false return behavior;
4. keep successful sends unchanged.

No AionCore change should be required.

Tests

Add focused regression tests covering:

1. successful send keeps the composer cleared;
2. false result restores the submitted prompt;
3. rejected send restores/recoverably preserves the submitted prompt;
4. rejected send does not overwrite new text typed while the request was pending;
5. Enter-key and send-button paths behave consistently.

Scope

Renderer / SendBox only.

Related context

• [Feature]: place prompt on clipboard before sending #3540 discussed protecting long prompts by copying them before send, but this bug is narrower: failed-send recovery should be correct at the SendBox state-management layer rather than relying on clipboard behavior.
• Discussion feat(sendbox): persist per-conversation drafts across app restarts #3703 proposes persisting unsent drafts across restarts; this issue is specifically about preserving the message when an in-flight onSend() rejects.

Contribution / campaign note

I would be happy to implement this with focused regression tests. If this is suitable for the AionUi x Kimi contributor campaign, please mark/convert it to a bonus issue and assign it to me before I open the PR, so I can follow the required contribution flow.