Render performance of date and range input components

Nobody has claimed this yet.

### Flux version

v2.19.0

### Livewire version

v4.4.4

### Tailwind version

v4.3.3

### Browser and Operating System

Chrome on Windows 11

### What is the problem?

Hi there!

We have been gradually rebuilding our platform using Flux components in order to streamline the UI and accessibility. One thing we have noticed though, is that date/range input components.

Our platform includes the ability to view invoices and edit individual invoice entries in-line. A single invoice can have 100-200 lines, each with a date picker. Unfortunately we can't paginate those views due to customer expectations. This results in a DOM size of ~183.000 nodes (excluding the rest of the page) when 200 pickers are present, causing massive rendering performance issues in Chrome (Firefox seems to barely handle this).

One solution we came up with is loading the actual picker UI only once as a template, lazy loading them onto a date picker when you actually click the input. This cuts initial nodes to render down to ~5.200 significantly improving performance while retaining full functionality.

The code we wrote isn't very usable to you, as it isn't universal JavaScript due to how our backend is constructed.

However, this approach might be useful for you when working on Flux performance 🫣

### Code snippets to replicate the problem

Nothing unique to paste. We use regular date and range inputs with the following preset selection:
`today thisWeek thisMonth thisQuarter thisYear lastWeek lastMonth lastQuarter lastYear allTime`

### Screenshots/ screen recordings of the problem

### How do you expect it to work?

Loading picker/popover UIs as a template once, as reusing that template to populate the actual UI when interacting with the input.

### Please confirm (incomplete submissions will not be addressed)

- [x] I have provided easy and step-by-step instructions to reproduce the bug.
- [x] I have provided code samples as text and NOT images.
- [x] I understand my bug report will be closed if I haven't met the criteria above.

Start by reproducing the issue with many date and range input components using the listed presets, then inspect how their picker/popover UIs are rendered. Compare initial DOM size and Chrome rendering performance with the picker UI reused from a template. Done means substantially fewer initial DOM nodes while date and range interactions retain their existing functionality.

Written by the indexing model from the issue text.