docs(openspec): archive phase 3d display input

openspec/specs/session-display-mode/spec.md

@@ -0,0 +1,38 @@
+# session-display-mode Specification
+
+## Purpose
+TBD - created by archiving change phase-3d-client-display-input. Update Purpose after archive.
+## Requirements
+### Requirement: Bounded display mode contract
+The Protocol SHALL define `DisplayMode` with required integer
+`resolution_width` from 320 through 16384, `resolution_height` from 200 through
+8640, and `fps` from 1 through 240, rejecting missing, unknown, or out-of-range
+fields.
+
+#### Scenario: Valid display mode
+- **WHEN** a client encodes a 2560 by 1440 display mode at 120 FPS
+- **THEN** generated Go, Rust, and Swift bindings accept the same exact values.
+
+#### Scenario: Invalid display mode
+- **WHEN** any dimension or FPS is outside its bound or an unknown field exists
+- **THEN** strict Protocol validation rejects the object.
+
+### Requirement: Feature-gated optional display disclosure
+`SessionRequest.requested_display_mode`,
+`BrokerSession.requested_display_mode`,
+`BrokerSession.effective_display_mode`, and `ManifestProfile.display_mode`
+SHALL be optional references to `DisplayMode`. Go bindings SHALL use pointers
+with JSON omission and Rust/Swift bindings SHALL use optionals. A client MUST
+send the request only after `display.request.v1` negotiation, and a
+display-aware manifest MUST contain the accepted mode. Legacy requests SHALL
+produce legacy response shapes without these fields.
+
+#### Scenario: Legacy request remains unchanged
+- **WHEN** a client omits `requested_display_mode`
+- **THEN** encoding omits the field and compatible Server responses omit all
+  display-mode fields.
+
+#### Scenario: Display-aware request discloses acceptance
+- **WHEN** a negotiated client sends a valid requested mode
+- **THEN** session responses preserve the requested mode and the allocated
+  manifest includes the Server-accepted mode.