All right, the AI actually found the issue based on the source! It was a 3rd party script conflict as I suspect, but I couldn’t find the source of it.
It’s a conflict between Ajax Search Pro and your active theme (theblog). The theme’s mega-menu component loads an old color-picker library called jscolor across the entire WordPress admin. That library automatically latches onto any color input on the page — including the ones in Ajax Search Pro’s settings — and because it doesn’t understand our color format, it silently resets the value back to a default. This should be also addressed by the theme developer, it is highly problematic to load global assets across the whole admin interface.
The reason it only showed up after saving twice: the first save reloads the page and our picker displays correctly, but jscolor then quietly overwrites the stored value in the background. The second save commits that overwritten value, so the reset only becomes visible on the next reload. That timing is also why it was so hard to reproduce on a clean setup — it only triggers when a theme/plugin like this is present, which is why your Mac/Safari/Chrome reports were spot on about it being a timing issue.
The fix
I’ve updated Ajax Search Pro so its color pickers can no longer be hijacked by jscolor (or any similar library), with an extra safeguard on top. This will be included in the next public release, but I’ve prepared a hotfix build for you right now: hotfix download
I have already installed it on your staging site. Please clear the browser cache and the issue should disappear.