feat: cache colors

[s-cerevisiae]

This PR adds cache for colors and palettes, following the practice of tokyonight.nvim. Colorschemes are compiled into a messagepack table on first load, and subsequent loads doesn't load lush.nvim at all. The startup time is reduced to ~2ms on my machine (on par with pre-compiled solution in #235), while allowing for configuration.

Note: a version field is added to zenbones.util which is expected to be updated by release-please. Not sure if it works this way.

Fixes #98.

TODO:

• Fix option cache for randombones
• Add an option to opt-out of caching
• Refactor each colorscheme so that get_global_config is not called twice Not necessary as this only happens once per cache write
• Less duplicated code in term.lua?

[s-cerevisiae]

Okay screw this CI-only tool, I've tried my best but if release-please still doesn't work after merging let's revert all the JSONs and switch to reading a version.txt file that contains 4.12.0 (which should be automatically updated) as I have zero ways to verify the config in action.

[evantravers]

I love this idea… watching with interest.

[s-cerevisiae]

I've been using this in different environments (Linux, macOS, Android) for quite a bit of time and it is working fine for me. Would you like to take a look at it when you have the time? @mcchrish

[evantravers]

@s-cerevisiae I gave your fork a whirl, and one thing I noticed is that it seemed to break switching between light and dark modes? I could have just integrated it incorrectly.

[s-cerevisiae]

Aww good catch. Looks like a dumb mistake in my code, I'll fix it soon

[s-cerevisiae]

Found another bug in the process... I'll fix both

[s-cerevisiae]

@evantravers I got both problems fixed, you can give it another go. Thanks for testing it!

[evantravers]

That seems to work.

My (lazy-as-heck) AI analysis of the --startuptime reports. I glanced at the final numbers, and it seems correct.

---

Here's the zenbones theme load comparison (from the Embedded process profiles):

zenbones load block (bones.vim → colors/zenbones.vim)

 ┌──────────────────┬─────────────────────┬─────────────────────────────┬──────────┐
 │                  │ start               │ end                         │ total    │
 ├──────────────────┼─────────────────────┼─────────────────────────────┼──────────┤
 │ before-cache.txt │ 023.043 (bones.vim) │ 034.650 (zenbones.vim done) │ ~11.6 ms │
 ├──────────────────┼─────────────────────┼─────────────────────────────┼──────────┤
 │ cache.txt        │ 024.536 (bones.vim) │ 025.907 (zenbones.vim done) │ ~1.4 ms  │
 └──────────────────┴─────────────────────┴─────────────────────────────┴──────────┘

Savings: ~10.2 ms, roughly 8.5× faster.

What's happening differently

before-cache — full lush compile path (~11.6 ms):

  023.043  sourcing autoload/bones.vim
  023.657  require('zenbones.util')         0.593
  024.977  require('lush.math') / vivid convert/type/lib files
  026.358  require('lush')                  2.698
  027.304  require('zenbones.palette')
  028.069  require('zenbones.specs.dark')
  029.145  require('lush.parser')           1.069
  031.630  require('zenbones')              5.272
  031.956  require('lush.compiler')
  034.608  require('zenbones.term')
  034.650  sourcing colors/zenbones.vim     12.239 self+sourced

cache.txt — just reads the precompiled output:

  024.536  sourcing autoload/bones.vim
  024.805  require('zenbones.util')         0.250
  025.257  require('zenbones.specs')        0.449
  025.907  sourcing colors/zenbones.vim     2.416 self+sourced

The cache path skips the entire lush/vivid compilation chain (lush, lush.parser,
lush.compiler, zenbones.palette, zenbones.specs.dark, HSLUV conversions) — it only needs
zenbones.util + zenbones.specs to load the generated colors.

As a side effect, total startup dropped too: NVIM STARTED at 062.696 → 056.899 (~5.8 ms
faster overall, essentially all of it attributable to the theme load).