Trim the Responses deviations section and remove the phone navigation section

The deviations section is two paragraphs: the three ways a provider can depart from the format and what Open WebUI does with each, then the limit, that content the provider never sent cannot be recovered.

The phone navigation section on the app installation page is removed.

Author: Classic298

docs/getting-started/open-webui-as-app.md

@@ -51,17 +51,6 @@ Safari is the only browser that supports PWA installation on iOS. Chrome and Fir
 
 ---
 
-## Getting Around on a Phone
-
-On a phone or tablet the sidebar slides in over the conversation instead of sitting beside it, and you move it with your finger:
-
-- **Drag right** anywhere on the screen to pull the sidebar in, **left** to push it away. It follows your finger and dims the chat behind it as it comes, and a quick flick settles it either way.
-- A swipe that opens the sidebar has to start clear of the **very edge of the screen**, so an edge swipe still reaches your browser or phone. Closing works from anywhere.
-- A mostly vertical drag scrolls the page as usual, and a drag started on a text field, a button or an open menu leaves the sidebar alone.
-- Every chat row carries an always-visible three-dot menu (⋯), so its actions do not depend on a hover you cannot perform.
-
----
-
 ## Customizing the PWA (Admins)
 
 Admins can white-label the PWA by pointing to a custom manifest with the [`EXTERNAL_PWA_MANIFEST_URL`](/reference/env-configuration#external_pwa_manifest_url) environment variable. This lets you set a custom app name, icon, and theme color.

docs/getting-started/quick-start/connect-a-provider/starting-with-open-responses.mdx

@@ -124,13 +124,9 @@ Tool calls, re-invocations, and streaming are supported for Responses API connec
 
 ### Providers that deviate from the Responses format
 
-Not every endpoint that advertises the Responses format emits it exactly. Open WebUI absorbs the most common deviations rather than losing the reply over them, so you should not need to work around any of them:
+Not every endpoint that advertises the Responses format emits it exactly, and Open WebUI absorbs the common deviations rather than losing the reply over them. A stream that closes reporting no content keeps whatever was already streamed. A fragment arriving before the item it belongs to is skipped without truncating the rest of the answer. A provider that hands over its finished message only at the very end has that message applied, so the reply and its citations are stored and carry into the next turn.
 
-- **A stream that closes by reporting no content.** Some providers end the stream saying the response contains nothing, even though they just streamed the whole answer. Open WebUI keeps what it received while streaming, so the reply stays on screen and is saved to the chat instead of blanking out the moment generation finishes. A provider that closes with a populated response of its own still takes precedence, so endpoints that follow the format are unaffected.
-- **Pieces of the response arriving out of order.** A fragment of message text, reasoning text or tool call arguments is skipped when it turns up before the item it belongs to, points past the end of the response or is not labelled the way the format expects. The rest of the stream is handled normally, so only that one fragment is dropped and the answer is not left truncated from there on. For a caller hitting `/api/chat/completions` directly, the body runs through to its `[DONE]` marker as usual, and the [`outlet()` filters that run when a message completes](/features/extensibility/plugin/functions/filter#filter-behavior-with-api-requests) are not skipped.
-- **A reply that only takes its final shape at the very end.** Some providers skip the events that mark where a message's text begins and ends, and hand over the finished message only once the item is complete. Open WebUI applies that finished message, so what is stored with the reply is what the provider actually produced: the answer carries into the conversation history the model sees when you ask your next question, and the citations attached to it are saved with the message and sent back on the next turn. The sources listed under the reply are read from the event as it arrives, so those were never at risk. Providers that emit the full sequence see no difference, because the finished message matches what was already streamed. Note that the finished message replaces what was streamed rather than merging into it, so a provider that hands back less than it streamed shortens the reply at that point: the full text returns if that provider then closes with a populated response, and is gone for good if it does not.
-
-Open WebUI cannot recover content the provider never sent. If replies are consistently short or empty, the problem is upstream; compare the same prompt against the provider's own API before reporting it here.
+Open WebUI cannot recover content the provider never sent. If replies are consistently short or empty, compare the same prompt against the provider's own API before reporting it here.
 
 ### Stateful sessions