Investigate BoxProps incompatibility in forwarding wrappers under mixed React Native type sources

Summary

After the ADR-0004 Box type migration, MetaMask Mobile hit TypeScript failures when consumer wrapper components extended BoxProps and then forwarded those props into <Box {...props} />.

The failure appears when the consumer dependency graph still exposes older @types/react-native callback types while @metamask/design-system-react-native resolves React Native 0.76 bundled types.

Repro shape

A minimal consumer-side pattern that can fail:

import { Box, BoxProps } from '@metamask/design-system-react-native';

interface WrapperProps extends Omit<BoxProps, 'children'> {}

export const Wrapper = (props: WrapperProps) => <Box {...props} />;

In MetaMask Mobile this surfaced most clearly on onLayout, where TS compared:

• @types/react-native LayoutChangeEvent
• vs React Native bundled LayoutChangeEvent

The JSX spread then failed even though BoxProps looks structurally correct.

Observed behavior

In MetaMask Mobile:

• BoxProps in forwarding wrappers can fail TS checks on native callback props like onLayout
• React.ComponentProps<typeof Box> works reliably because it matches the actual JSX contract of the concrete Box component
• Removing/hiding node_modules/@types/react-native in a local repro made the HeaderSearch onLayout mismatch disappear

Why this matters

Mobile is temporarily using React.ComponentProps<typeof Box> in forwarding wrappers to unblock the stable design-system release pipeline, but this is a consumer-side workaround. We should decide whether MMDS can provide a clearer or safer library-side path.

Questions to resolve

• Is the root cause entirely consumer-side mixed RN type identity, or does the exported BoxProps alias shape contribute?
• Should MMDS explicitly document that forwarding wrappers should prefer React.ComponentProps<typeof Box> over BoxProps?
• Should MMDS export an official wrapper-safe alias such as BoxComponentProps?
• Can emitted declarations or package typing strategy be improved to reduce this mismatch for consumers still carrying DT React Native packages?

Suggested acceptance criteria

• Reproduce the issue in a small consumer fixture
• Confirm whether mixed RN type sources are sufficient to trigger it
• Decide on the recommended library guidance and/or exported type surface
• Document the intended consumer pattern for forwarding wrappers

Related context

• MetaMask Mobile PR: https://github.com/MetaMask/metamask-mobile/pull/28840
• Relevant MMDS work: ADR-0004 centralized shared types for Box