Discovery - revisit `any` usage and conditional `string | string[] | null` prop types

Nobody has claimed this yet.

After bumping to React v19, [this conditional typing](https://github.com/lsst-epo/epo-react-lib/blob/d6821e0aaea1673d4bd5971eaca6e7cd46035402/packages/epo-react-lib/src/form/SelectListbox/SelectListbox.tsx#L10-L44) in this component had to change to [this non-conditional typing](https://github.com/lsst-epo/epo-react-lib/blob/develop-v3/packages/epo-react-lib/src/form/SelectListbox/SelectListbox.tsx#L10-L26). The usage for the former conditional typing was sprinkled throughout the codebase and typing issues ensued moving to the latter non-conditional typing. This mostly was an easy fix, but the `ColorTool` required temporary `any` typing usage to unblock the dev group in order to hit a Hazardous Asteroids milestone.

Several things need to be sussed out:

1. Why was the conditional typing implemented in the first place? What problem did it solve and why weren't two wholly separate components created? Or why wasn't an interface used with an override for the use case where the `string[]` was used?
2. Should the `SelectListBox` be redesigned to be not as flexible as in the past? My gut feel is yes, this would provide a consistent solution across the monorepo, but would also likely require the creation of a new component with an interface type that overrides the `string` to `string[]` type
3. Should we keep the original `string | string[] | null` typing? Following the stack through the errors leads to web APIs that don't accept `string[]` - what do we do here?

This is a non-blocking issue and using `any` was intentionally a temporary solution, but we should be wary of any `any` usage and use it as sparingly as possible.

Start by comparing the conditional and non-conditional SelectListbox typings at the linked SelectListbox.tsx locations, then trace the affected ColorTool usage and the web API errors mentioned in the issue. Determine why the original typing existed, whether the component API should change, and how string[] values should be handled. Done means the typing approach and any remaining any usage have a documented, consistent resolution across the monorepo.

Written by the indexing model from the issue text.