Complete Split column visibility commands with UIKit hide(column)

[juliusmarminge]

Split.Host exposes UIKit's preferredDisplayMode property and show(column) command, but does not expose the matching hide(column) command.

Apple documents that assigning preferredDisplayMode changes the layout immediately unless the assignment occurs in an animation block. For column visibility changes, it recommends show(_:) and hide(_:), which choose the closest supported display mode and provide a native transition coordinator:

• preferredDisplayMode
• show(_:)
• hide(_:)

A complete current-API example for FabricExample, rendered as the top-level App on an iPad:

import React from 'react';
import { Button, Text, View } from 'react-native';
import { Split } from 'react-native-screens';

export default function App() {
  const [visible, setVisible] = React.useState(true);
  return (
    <Split.Host
      preferredSplitBehavior="tile"
      preferredDisplayMode={visible ? 'oneBesideSecondary' : 'secondaryOnly'}>
      <Split.Column>
        <View style={{ flex: 1, backgroundColor: '#d6eaff' }}>
          <Text>Primary</Text>
        </View>
      </Split.Column>
      <Split.Column>
        <View style={{ flex: 1, justifyContent: 'center' }}>
          <Text>Secondary</Text>
          <Button title="Toggle primary" onPress={() => setVisible(v => !v)} />
        </View>
      </Split.Column>
    </Split.Host>
  );
}

That property's immediate transition agrees with UIKit. Changing it to animate by default would change existing behavior and require the library to choose a duration and curve.

I propose completing SplitHostCommands instead:

show: (column: SplitNavigableColumn) => void; // existing
hide: (column: 'primary' | 'supplementary') => void;

hide would forward directly to UISplitViewController.hideColumn: and use the same ref/codegen/lifecycle path as show. UIKit does not support hiding secondary, so the new public type should exclude it. Inspector visibility would continue to use showInspector.

Applications could use hostRef.current?.hide('primary') and the existing show('primary') for user-triggered sidebar transitions without writing native animation timing or feeding onDisplayModeWillChange back into preferredDisplayMode. Property initialization, removal/reset to automatic, and compact/adaptive layout would keep their current semantics. UIKit would own native interaction, interruption, and accessibility behavior.

Would this be an acceptable small addition? I am preparing a focused main-based PR and comparing the example against a standalone UIKit split controller, including rapid retoggling and Reduce Motion. This does not depend on the split-stack prototype in #4666. React Navigation's current v5 adoption draft has no split navigator to adapt, so its split integration remains a downstream gate.