Callers currently hand this function a trimmed description, so the output is
always clean. An upcoming change to the commit-panel getters will stop trimming
at the callsite (so that whitespace typed by the user round-trips through the
preservation file exactly), at which point the description can end with one or
more newlines. Without this change, a user who presses Enter after their
description body and then invokes "Add co-author" would end up with two blank
lines between the body and the trailer instead of the expected one.

…t messages

Typing a description with leading blank lines, canceling the commit panel, and
reopening it currently drops leading blank lines.

This is useful when cancelling out of the commit panel mid-sentence (after
having typed the space for the next word); when entering the commit message
panel again, the space was gone and you had to type it again. Small thing, but
it just seems better to resume the panel in exactly the state that you left it
in. (Which we actually don't do; we don't remember the cursor position, or which
of the subject/description panels was active. That would be a separate
improvement.)

The save path and the load path used to be asymmetric. On save, the textarea
getters applied strings.TrimSpace, which stripped any leading blank lines, a
trailing newline after the cursor, or indentation on the very first line of the
description — all of which are legitimate user content. On load,
SplitCommitMessageAndDescription did TrimSpace on the description as well, and
the preserved message was routed through that same git-format split because
HandleCommitPress passed it as OpenCommitMessagePanel's InitialMessage. The
result: every round-trip through "escape and reopen" silently mutated the
message.

The fix is to treat our own preservation file as its own format, distinct from
git's canonical "summary\n\nbody" format:

- The textarea getters return raw content. strings.TrimSpace moves to the one
  place that still needs it: the empty-summary check in HandleCommitConfirm (git
  itself strips trailing whitespace and blank lines, so no pre-trim is needed
  before -m).
- SplitPreservedCommitMessage / SetPreservedMessageInView split on the single
  "\n" our Join uses, without any trimming — truly lossless.
- SplitCommitMessageAndDescription keeps its git-format behavior but replaces
  TrimSpace with TrimPrefix("\n"), so it strips only the blank-line separator
  and leaves body indentation intact.
- HandleCommitPress now mirrors HandleWIPCommitPress: it no longer passes the
  preserved message as InitialMessage. OpenCommitMessagePanel resolves the
  preserved content itself, uses it for display via the preservation-format
  setter, and stores it as the initial message so the close-time "did the user
  change anything?" check still correctly detects a cleared panel.
- GetInitialMessage no longer trims. With raw getters on both sides of the
  comparison, trimming here caused spurious non-matches (e.g. for preserved
  content with trailing whitespace). The original motivation — matching a
  "WIP: " prefix with trailing space — works unchanged.
- UpdateCommitPanelView becomes dead code and is removed; its one remaining
  caller (history cycling, always git-format) goes directly through
  SetMessageAndDescriptionInView.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>