feat: "Return to submit" keyboard preference (Enter to send, Shift+Enter for newline)

[soyasis]

What

Adds an optional "Return to submit" preference (Settings → General). When on, a bare Return submits and Shift+Return inserts a newline. Everywhere the app currently uses ⌘+Return to submit. Off by default, so nothing changes for existing users unless they opt in.

Closes #32.

Why

⌘+Return-to-submit isn't discoverable and doesn't match the muscle memory of chat-style apps. This makes Enter-to-send a global, opt-in preference rather than an Ask-AI-only tweak.

Where it applies

All six submit surfaces, driven by one shared decision:

• Ask AI box & "New Chat"
• Result follow-up
• MCP connector form
• Destination add/edit form
• Custom shortcut form
• Inline LLM directive editor (chain steps)

How

The submit-vs-newline rule lives in one pure function, WindowController.returnSubmitsPrompt(...) , consulted by both keyboard substrates: the floating-window key monitor (Ask AI / follow-up / MCP) and ForwardingTextView (the MultilineTextEditor forms). Rule: only a bare Return submits; Shift/Option/Control+Return insert a newline; ⌘+Return always submits. The setting (CaiSettings.pressReturnToSend) lives in General with a symbol subtitle.

Testing

• EnterToSendTests — 8 cases over the pure predicate (off/on, bare vs Shift/Option/Control/CapsLock, in/out of a submit screen).
• Manual: verified all six surfaces in both toggle states — Enter submits when on, ⌘+Return submits in both states, Shift+Return inserts newlines.

Notes

• In the multi-field forms (MCP / Destinations / Shortcuts), with the setting on a bare Return submits the whole form and Shift+Return inserts a newline — the intended tradeoff for app-wide consistency.
• Default off → zero behavior change until opted in.