## ADDED Requirements

### Requirement: P3D-033 requested and effective display mode
The client SHALL offer global and desktop/pool overrides for Automatic, detected/common preset, Custom, and Full Native width/height/FPS. A display-aware request SHALL be feature-gated; the Server SHALL validate, include it in idempotency identity, resolve immutable policy, proportionally clamp to even dimensions and maximum FPS, persist requested/effective values atomically, and disclose both without provider details.

#### Scenario: Oversized custom request
- **WHEN** a requested mode exceeds either policy dimension or FPS
- **THEN** the Server applies one proportional scale, floors both dimensions to even pixels, caps FPS, persists the result, and returns the requested and accepted modes

#### Scenario: Legacy request
- **WHEN** a client omits the feature and requested display object
- **THEN** the Server preserves the legacy response shape and provider work uses the existing exact policy mode

#### Scenario: Same idempotency key with different mode
- **WHEN** two requests reuse an idempotency key but contain different requested display modes
- **THEN** the Server rejects the mismatch rather than returning or mutating the earlier session

### Requirement: P3D-034 native detection and reconnect semantics
Automatic mode SHALL derive physical pixels and maximum FPS from the screen where the session window opens, prefer a defensible notch-safe built-in mode, otherwise disclose Full Native, and SHALL NOT mutate an active mode after a display move. Reconnect to match the new display SHALL end the prior session and use a new request/idempotency key. Owner E2E SHALL prove accepted values on Apollo/SudoMaker IDD through the gateway-only route.

#### Scenario: Move active session to another display
- **WHEN** an Automatic session window moves to a display with different native capability
- **THEN** the active mode remains unchanged and the user may explicitly reconnect with a newly detected request

#### Scenario: Exact owner virtual-display acceptance
- **WHEN** the owner runs the frozen client, Server, gateway, and Apollo candidate
- **THEN** retained evidence binds requested and accepted width/height/FPS to the actual SudoMaker virtual display without a direct client-provider route