[BUG]: validate_colors and convert_colors_to_same_type modify the colors passed to them #5846

Description

plotly.colors.validate_colors and plotly.colors.convert_colors_to_same_type modify the list passed to them instead of working on a copy. This has two visible effects:

• Built-in color sequences get rewritten. Passing a built-in sequence such as plotly.colors.sequential.Inferno to convert_colors_to_same_type rewrites that module-level list for the rest of the Python session. Any later figure or validator that uses Inferno then sees rgb(...) strings instead of the original hex values.
• The default colors get corrupted. validate_colors(None) falls back to DEFAULT_PLOTLY_COLORS and converts that list in place, so the defaults become float tuples. ff.create_trisurf calls it this way whenever colormap is left as None. A user-supplied colormap list is also converted in place.

I came across this while reading the color utilities and confirmed it with the snippet below. It also explains an order-dependent failure in the existing test suite: running tests/test_core/test_colors before tests/test_plotly_utils makes test_colorscale_validator.py::test_acceptance_named[Inferno_r] fail on main, because test_sample_colorscale has already rewritten Inferno.

Steps to reproduce

import plotly.colors as pc

print(pc.sequential.Inferno[:2])
# ['#000004', '#1b0c41']

pc.convert_colors_to_same_type(pc.sequential.Inferno, colortype="rgb")
print(pc.sequential.Inferno[:2])
# ['rgb(0, 0, 4)', 'rgb(27, 12, 65)']   <- the built-in sequence was modified

print(pc.DEFAULT_PLOTLY_COLORS[:1])
# ['rgb(31, 119, 180)']

pc.validate_colors(None)
print(pc.DEFAULT_PLOTLY_COLORS[:1])
# [(0.12156862745098039, 0.4666666666666667, 0.7058823529411765)]   <- defaults changed

The same happens with any list a user passes in, e.g. a custom colormap given to ff.create_trisurf.

Expected behavior

Both helpers should leave their input unchanged and return the converted colors, as their return values already suggest. Built-in sequences and DEFAULT_PLOTLY_COLORS should keep their original values for the whole session.

Notes

#5836 fixes this by copying the list before converting it. The return values stay the same, and the PR adds a test that checks the inputs are left untouched.