Design and prove iPad power workflows beyond adaptive phone parity

[altaywtf]

Parent

#151

What this delivers

The SwiftUI iPad app uses the larger screen and Apple input model deliberately: persistent context, efficient file operations, keyboard navigation, drag and drop, and multiwindow behavior instead of a stretched phone layout.

Scope

• Define sidebar/list/detail behavior and preservation of folder/file selection across width changes.
• Add keyboard navigation and shortcuts for common file, search, playback, and selection actions.
• Support drag and drop where it creates a clear file-cloud or system-export workflow.
• Prove multiwindow and Stage Manager behavior, including state ownership and account/session consistency.
• Coordinate system export and Files behavior with Integrate with Apple Files and system export workflows #93 rather than duplicating it.
• Preserve touch-first accessibility and clear alternatives for every shortcut or drag action.

Acceptance criteria

• Core files, search, offline, playback, and settings paths use an approved iPad layout rather than stretched phone navigation.
• Keyboard users can navigate and perform the supported core actions without touch.
• Drag/drop and multiwindow behaviors have explicit supported and unsupported boundaries.
• Rotation, resizing, Stage Manager, and scene restoration preserve valid navigation and selection state.
• VoiceOver, Dynamic Type, and pointer behavior remain usable.

Verification

• State and navigation tests for compact/regular transitions and scene restoration.
• iPad simulator plus physical-device proof for keyboard, pointer, drag/drop, resizing, and multiwindow behavior.
• Screenshots or recordings attached to the PR for each accepted layout/input mode.

Blocked by

None. Coordinate overlapping system-export work with #93.

Boundaries

• No separate iPad product or duplicated data layer.
• No macOS or visionOS target.
• Do not hide unsupported behavior behind inert controls.