Create unified Display Modes section

Consolidate all display mode documentation into a single section:
- Display mode types (inline, fullscreen, pip)
- Declaring support from View (appCapabilities.availableDisplayModes)
- Declaring support from Host (HostContext.availableDisplayModes)
- Requesting changes (ui/request-display-mode)
- Notifying changes (ui/notifications/host-context-changed)
- All MUST/SHOULD requirements for View and Host behavior

The ui/request-display-mode in Requests section now references
the Display Modes section for behavior details.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

Author: martinalong

specification/draft/apps.mdx

@@ -730,6 +730,63 @@ bridge.onsizechange = ({ width, height }) => {
 
 Apps using the SDK automatically send size-changed notifications via ResizeObserver when `autoResize` is enabled (the default). The notifications are debounced and only sent when dimensions actually change.
 
+### Display Modes
+
+Views can be displayed in different modes depending on the host's capabilities and the view's declared support.
+
+```typescript
+type McpUiDisplayMode = "inline" | "fullscreen" | "pip";
+```
+
+- **inline**: Default mode, embedded within the host's content flow
+- **fullscreen**: View takes over the full screen/window
+- **pip**: Picture-in-picture, floating overlay
+
+#### Declaring Support
+
+**View (`appCapabilities.availableDisplayModes`):**
+
+Views declare which display modes they support in the `ui/initialize` request via `appCapabilities.availableDisplayModes`. This allows hosts to only offer display mode options that the view can handle.
+
+```typescript
+// Example: View declares support for inline and fullscreen
+{
+  method: "ui/initialize",
+  params: {
+    appCapabilities: {
+      availableDisplayModes: ["inline", "fullscreen"]
+    },
+    // ...
+  }
+}
+```
+
+**Host (`HostContext.availableDisplayModes`):**
+
+Hosts declare which display modes they support in `HostContext.availableDisplayModes`. Views should check this before requesting a mode change.
+
+#### Requesting Changes
+
+Views request display mode changes via `ui/request-display-mode`. See the Requests section for message format.
+
+#### Notifying Changes
+
+Hosts notify views of display mode changes via `ui/notifications/host-context-changed` with the `displayMode` field.
+
+#### Requirements
+
+**View behavior:**
+- View MUST declare all display modes it supports in `appCapabilities.availableDisplayModes` during initialization.
+- View MUST check if the requested mode is in `availableDisplayModes` from host context before requesting a mode change.
+- View MUST handle the response mode differing from the requested mode.
+
+**Host behavior:**
+- Host MUST NOT switch the View to a display mode that does not appear in its `appCapabilities.availableDisplayModes`, if set.
+- Host MUST return the resulting mode (whether updated or not) in the response to `ui/request-display-mode`.
+- If the requested mode is not available, Host SHOULD return the current display mode in the response.
+- Host MAY coerce modes on certain platforms (e.g., "pip" to "fullscreen" on mobile).
+- Host MAY decline display mode requests from Views that did not declare said modes in their capabilities.
+
 ### Theming
 
 Hosts can optionally pass CSS custom properties via `HostContext.styles.variables` for visual cohesion with the host environment.
@@ -998,17 +1055,7 @@ Host behavior:
 }
 ```
 
-Host behavior:
-* Host MUST NOT switch the View to a display mode that does not appear in its `appCapabilities.availableDisplayModes`, if set.
-* It is up to the host whether it switches to the requested mode, but the host MUST return the resulting mode (whether updated or not) in the response.
-* If the requested mode is not available, Host SHOULD return the current display mode in the response.
-* Host MAY coerce modes on certain platforms (e.g., "pip" to "fullscreen" on mobile).
-* Host MAY decline display mode requests from Views that did not declare said modes in their capabilities.
-
-View behavior:
-* View MUST declare all display modes it supports in `appCapabilities.availableDisplayModes` during initialization.
-* View MUST check if the requested mode is in `availableDisplayModes` from host context before requesting a mode change.
-* View MUST handle the response mode differing from the requested mode.
+See the Display Modes section for detailed behavior requirements.
 
 `ui/update-model-context` - Update the model context