[Calendar] Support ref as prop and fix date handling edge cases

Summary

Improvements to the Calendar, DatePicker, and RangePicker components to fix patterns and improve flexibility.

Improvements

1. No ref prop support on Calendar, DatePicker, or RangePicker

None of the three exported components accept ref as a prop, inconsistent with the rest of the design system.

2. Hardcoded future date restriction in DatePicker

DatePicker input validation has dayjs(date).isSameOrBefore(dayjs()) hardcoded, preventing selection of future dates. This should be configurable or removed.

4. Manual event listener management in DatePicker

DatePicker manually manages mouseup event listeners via document.addEventListener/removeEventListener. This could be simplified using the Popover's own onOpenChange interaction model or a useEffect cleanup pattern.

5. mode='single' hardcoded in Calendar

The Calendar component sets mode='single' by default but also spreads ...props after, which allows override. The default should be documented or the prop should be explicit in the type.

6. DatePicker input format detection is fragile

handleInputChange guesses the date format based on separator character (/ or -). This can conflict with the dateFormat prop if the user specifies a different format.

Moved to Cross-Cutting Issues

The following items have been moved to cross-cutting issues that address them across all components:

• Remove !important declarations (#678)

Start with the Calendar, DatePicker, and RangePicker component entry points and inspect their prop types and date-handling paths. Review ref support, future-date validation, mouseup listener cleanup, Calendar's single mode default, and input format detection against the stated improvements. Done means the affected behavior is configurable or corrected across the three components, with the existing design-system patterns preserved.