This PR fixes #7506

Description

When using Plotly.react to update the data of a histogram with barmode: 'overlay', if the traces contain single data points (one point per trace), the calculated bin.size could incorrectly set to 1. This results in the histogram bars becoming visually very thin after a data update.

This issue is particularly noticeable for react-plotly users, where data mutations are frequent.

Changes

This new logic ensures that auto-binning is correctly triggered when usingPlotly.react (for data mutations).

Before/After

See the fixed look in #7506 (comment).

Note on Plotly.react and layout object

This PR directly fixes the incorrect histogram auto-binning size calculation for single-point traces in overlay mode on data updates. However, it's worth noting that this issue is often triggered by a deeper behavior within Plotly.react concerning layout object reuse. See the Note in #7506.

I found that if the same layout object is reused in Plotly.react calls while the data's axis type (xaxis.type in layout) changes (e.g., from linear to category), the layout object can become "stuck" (stale) with the last-used axis type. For instance, after switching from numeric to string data, the axis type becomes category. When switching back to numeric data, the axis type incorrectly remains category, leading to rendering issues.

The long-term solution might involve changes to how Plotly.react handles the layout object. For now, the good practice for users might be: if your data update might change the axis type (i.e., change the layout), you should also provide a new layout object (or a deep copy) to Plotly.react to ensure correct rendering.

The test case added in this PR (histogram_test.js) intentionally uses data of the same type (linear, auto-detected by Plotly) to specifically test the auto-binning fix when data changes, without being affected by the separate layout reuse behavior.