Gradients should interpolate in a perceptually linear colour space

Gradients are currently determined via linear interpolation in the non-linear sRGB colour-space, which results in some undesirable hue and lightness shifts as a result.

[OKLab](https://bottosson.github.io/posts/oklab/) (and its cylindrical counter-part, OKLCh) is an industry-standard perceptually linear colour-space, which is supported in baseline CSS (i.e. available in all modern browsers), and a variety of other applications. It is designed to be performant while making colour specification and transitions more intuitive.

I'm unsure whether this software can make use of CSS functions like `linear-gradient(in oklab, , )`, but that (or something equivalent, like directly querying the `oklab` colour space for interim gradient points) would allow gradients to perceptually make more sense than linear interpolation in the non-linear sRGB space. If it's relevant, gradients calculated in `oklch` tend to be more vibrant and colourful (so may be a worthwhile consideration), but are also a little less intuitive, because they can pass through different colours as the sweep around the hue circle.

If colours are able to be _defined_ in a space like `oklab` or `oklch` as well, then that also future-proofs the application for screens with wider colour gamuts than sRGB (there are already a variety that support Display P3 and Rec2020, including all recent Apple devices), which allows for more vibrant colours to be represented (which can be valuable for data differentiation).

---

As some legacy context, the original Ping Viewer supports up to 50 colours in a gradient, specified via [a text file of hex codes](https://docs.bluerobotics.com/ping-viewer/display-settings/#custom-gradients), which allows for customisations like roughly [perceptually smooth colour schemes](https://discuss.bluerobotics.com/t/ping-viewer-custom-gradients/8558/3) (without excessive drifting from non-linear-colour-space interpolation).

The current approach here of (seemingly max 10?) colours, with no mechanism for bulk input, makes it much harder to fine-tune, but I also think that's less important if the space itself is perceptually linear. A gradient file import and export mechanism would still be _nice_, if possible.

The issue does not name files or tests. Start by locating the gradient interpolation and colour-definition entry points, then determine whether CSS `linear-gradient(in oklab, ...)` or direct OKLab/OKLCh calculations are feasible. Done would mean perceptually linear gradients, with wider-gamut colour definitions and gradient import/export treated as optional follow-up scope.

Written by the indexing model from the issue text.