fix(web): preserve Shift+Enter on iPad hardware keyboards#23449

Problem

With Send shortcut → Enter, Shift+Enter can submit instead of inserting a newline in iPad Safari's Home Screen web app (#14869). The reporter's native keyboard trace contains shiftKey: true; ProseMirror's iOS Enter fallback later calls the composer with a synthetic Enter event that has no modifiers.

Change

Route non-composing iOS Shift+Enter through the existing composer key handler from handleDOMEvents.keydown, before ProseMirror replaces the event. Other modifiers and active composition retain their existing paths. The same editor covers rich-text and plain-text mode. The custom path retains the disabled-view guard and the native keydown path's deferred DOM-observer flush before invoking commands; the latter uses a narrowly typed ProseMirror internal property because no public flush API is exposed.

Scope and approval

This is a small, focused correction of the documented Shift+Enter behavior, submitted under the small obvious-bug exception. It adds one guard and regression coverage; it introduces no setting or product-behavior choice. Related maintainer triage and the identified iOS fallback candidate. That triage is not presented as approval of this implementation.

Fixes #14869.

Verification

• Failing test first: the new browser test initializes the iPad desktop Safari identity before ProseMirror is evaluated, then dispatches hardware-style Enter events with fake timers. On the unpatched base, both rich/plain cases hit the unmodified synthetic Enter and call the submission callback. With the fix, Shift+Enter inserts a newline without submission, plain Enter still submits once, and active composition stays untouched even if the event's isComposing flag is false.
• Review regressions (fa312ab7): both rich/plain cases now also replace native text and move the DOM caret while an observer flush is deferred. Without the flush, the middle-of-text newline corrupts the draft (line! one\n one instead of line!\n one); with it, the text and caret are synchronized before splitting. Separate cases focus the composer, disable it, and verify Shift+Enter invokes no command and leaves the draft unchanged. All four cases failed before these corrections and pass after them. This models a deferred observer, not a new physical iPad reproduction.
• Published release check: separately downloaded the official 0.1.2-nightly.20261022.3512 macOS arm64 archive and verified SHA256. In its unpatched client, the same automated iOS-path replay reaches the editor with shiftKey absent and consumes Shift+Enter without adding a paragraph. A separate editor copy with the proposed guard preserves Shift and adds the paragraph. Original release files were not modified. This is Chromium exercising the iOS code path, not a physical Safari reproduction.
• Real device: iPadOS 26.6.1, Magic Keyboard (hardware 0007, firmware 0400.0140.0303), Home Screen standalone web app, Send shortcut Enter. On the reporter's installed 0.0.46-nightly.20261014.3093, Shift+Enter submitted before the patch. After a client-only backport, Shift+Enter followed by plain Enter produced one two-line message; the new trace has no beforeinput: insertParagraph for Shift+Enter while plain Enter retains it. An unmodified latest-nightly test on the physical iPad is still outstanding.
• vp run check:changed — format, lint, knip, affected typechecks, and 18 tests across 3 files passed, on base 96bae5465bc5.
• vp run --filter @t3tools/web build — passed on the initial PR head 05996a2; not repeated for the review corrections.

Automated replay evidence (the explanatory overlay belongs to the test harness):

Before/after recording. These are test artifacts hosted on the fork, not application releases or physical iPad recordings. No evidence assets or local diagnostic/backport code are included in the PR.

Implemented with GPT-6.1-Sol through the Codex harness in T3 Code.

Fixes pingdotgg/t3code#14869