Custom CSS: Non-int RGB values added in the Additional CSS section cause fatal errors.

### Issue

If an RGB color is added in the additional CSS box via the Customizer and one of the values is a non-int (such as `rgb(20, '30px', 40) )`, then a fatal error is logged:

```
Uncaught TypeError: dechex(): Argument #1 ($num) must be of type int, string given in /jetpack_vendor/automattic/jetpack-mu-wpcom/src/features/custom-css/csstidy/class.csstidy-optimise.php:313
```

A warning will also display: `Looks like something’s gone wrong. Wait a couple seconds, and then try again.`

### How to replicate

I could only replicate on Simple.

* With a legacy theme active, for example Sketch, visit the Customizer > Additional CSS section. Add the following CSS:
```
a {
color: rgb(20, '30px', 40);
}
```
* You will see a warning notice in the customizer.
* If you are tailing the errors in your sandbox - `tail -f /tmp/php-errors` - you'll also see the fatal error mentioned above.

### Solution

Better validation would prevent the fatal error. However if that means no warning is displayed, then we're better off returning a non-string default value in the UI as well as behind the scenes otherwise it would cause confusion.

The issue is happening in `class.csstidy-optimise.php`, within the `cut_color` function.

### Other notes

Slack discussion: p1737969277822119/1737801967.683319-slack-C034JEXD1RD

Reproduce the issue in the Customizer's Additional CSS section with the provided RGB value, then inspect jetpack_vendor/automattic/jetpack-mu-wpcom/src/features/custom-css/csstidy/class.csstidy-optimise.php and its cut_color function. Trace how invalid RGB components reach dechex(); done means the input no longer causes a fatal error and the UI and backend return a consistent non-string default or validation result.

Written by the indexing model from the issue text.