Expose responsive prop on DatePicker/DateRangePicker (and other pickers) to opt out of automatic xs-breakpoint Drawer

Environment

• rsuite: 6.2.2
• React: 19.2.7

Feature request

PickerToggleTrigger (the shared internal base for DatePicker, DateRangePicker, SelectPicker, Cascader, etc.) already supports a responsive prop:

internals/Picker/PickerToggleTrigger.js:

const {
  ...
  responsive = true,
  ...
} = props;
const breakpoint = useBreakpointValue({ xsOnly: 'xs' }, { enabled: responsive });
const effectiveBreakpoint = disabled ? undefined : breakpoint;
...
overlayAs: effectiveBreakpoint === 'xs' ? PickerDrawer : undefined

So when responsive is true (the default) and the viewport matches the xs breakpoint (max-width: 575.99px), the popup automatically swaps to PickerDrawer (a fullscreen bottom-sheet-style drawer) instead of the normal popover.

The prop is even typed in PickerToggleTrigger.d.ts:

/** Whether the component should be responsive */
responsive?: boolean;

However, none of the public top-level components forward it. I checked DatePicker.js, DateRangePicker.js, SelectPicker.js, and Cascader.js — each explicitly enumerates the props passed into PickerToggleTrigger, and responsive isn't among them. PickerBaseProps (the shared base type extended by e.g. DatePickerProps) also has no responsive field. So there is currently no supported way to opt out of the automatic xs-breakpoint drawer behavior from application code — passing responsive={false} to <DatePicker> does nothing (it just gets forwarded to the underlying <input> as an unrecognized DOM attribute via the "rest props" path).

This matters for apps that already implement their own responsive/mobile handling around these pickers (e.g. a custom bottom-sheet wrapper below a different breakpoint) — the built-in xs auto-drawer can't be disabled, so it ends up conflicting with app-level responsive UI.

Request

Please forward responsive from the public component props (DatePickerProps, DateRangePickerProps, and ideally the other pickers built on PickerToggleTrigger) down to PickerToggleTrigger, and add it to the corresponding public .d.ts types (e.g. PickerBaseProps). Default should stay true to preserve current behavior — this is purely about making the existing internal capability actually reachable from app code.

I worked around this locally with a pnpm patch on DatePicker.js/DatePicker.d.ts that does exactly this (destructure responsive = true and pass it through to PickerToggleTrigger), so I can confirm it's a small, low-risk change — happy to open a PR with the same approach applied across the other pickers if that's welcome.