fix(prompt): don't implicitly set 'modified' #38118

Problem:
In aec3d7915c Vim changed prompt-buffers
to respect 'modified' so the termdebug plugin can "control closing the
window". But for most use-cases  (REPL, shell, AI "chat", …),
prompt-buffers are in practice always "modified", and no way to "save"
them, so *implicitly* setting 'modified' is noisy and annoying.

Solution:
Don't implicitly set 'modified' when a prompt-buffer is updated.
Plugins/users can still explicitly set 'modified', which will then
trigger the "E37: No write since last change" warning.

src/nvim/options.lua

@@ -5935,8 +5935,11 @@ local options = {
         result of a BufNewFile, BufRead/BufReadPost, BufWritePost,
         FileAppendPost or VimLeave autocommand event.  See |gzip-example| for
         an explanation.
-        When 'buftype' is "nowrite" or "nofile" this option may be set, but
-        will be ignored.
+        When 'buftype' is "nowrite" or "nofile", this option may be set, but
+        it is ignored and will not block closing the window. For "prompt"
+        buffers, changes made to the buffer do not make it count as modified,
+        but an explicit ":set modified" is respected and will block closing the
+        window.
         Note that the text may actually be the same, e.g. 'modified' is set
         when using "rA" on an "A".
       ]=],