Color css files are not regenerated when deploying through configuration management

We needed this for an Opigno-based project so I re-rolled #68 against 1.0.3 if helpful.

Updated patch to remove casting errors and improper string var to function.

Fix from #68 for color in 9.4.x with PHP 8.1 deprecation fix in rgbToHex().

I want to set this to "Needs review", maybe even RTBC... I don't know why, but I can't set one of these patches to test against the 2.x branch, so it shows that it fails to apply to 1.x. I am using the 1.x version of the patch in my project, and it is solving this issue for me... I'm curious if this task has some actionable steps now to document?

The last submitted patch, 71: 2995825-71.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

We've been using the patch from #73 since it arrived, without issue.

I tested on the 1.x version and Drupal 10.1. The patch in #73 fails to apply, #72 works fine, and did not see any issues with aggregation as well.
It seems to work as expected, but I'm not sure if making methods private is a good idea - decorating the service is problematic. I need to duplicate many methods to apply some additional color replacement logic there.

There is a bug inside the hash calculation. The $cache_context_keys is not different and the problem appears when there are two themes enabled (in my case, the main theme and sub-theme). The [theme]= context key is wrong, it was gin (admin theme), not the theme that was provided as a function parameter, so the hash was the same and it generated one set of the CSS files and skipped it later because the hash was in cache already.

So I added this before the hash function:

    foreach ($cache_context_keys as $key => $value) {
      if (str_starts_with($value, '[theme]')) {
        $cache_context_keys[$key] = '[theme]=' . $theme;
      }
    }

then it started to work.