fix(theme): NeoVim body follows the variant, not just the tabline

[Rynaro]

Problem

Setting a non-dark variant (sepia/white) only recolored the NeoVim tabline — the editor body stayed dark blue.

Root cause — load order

alchemists-orchid.nvim (v2.0) ships plugin/alchemists-orchid.lua that eagerly runs setup() (its dark default) plus colorscheme alchemists-orchid. Vim sources plugin/** scripts after init.vim, so:

1. init.vim sources generated/palette.vim → setup({mode='light'}) → body correctly becomes sepia/white.
2. After init.vim, Vim auto-runs the plugin's plugin/*.lua → setup() (dark) → body reverts to dark.

That step-2 colorscheme alchemists-orchid fires Potions' ColorScheme autocmd, which repaints only the barbar tabline / Visual / cheat groups from the variant tokens — so the tabline tracked the variant while the body did not. Exactly the reported symptom.

Proven empirically: under the real init.vim, Normal resolved to #2e3440 (dark); re-sourcing palette.vim flipped it to the parchment surface.

Fix

In the nvim adapter (.potions/lib/theme/adapters.sh):

• Wrap the body apply in a re-callable global PotionsApplyOrchid() (still invoked immediately — so live :source / potions reload keeps winning, since no plugin pass follows a live source).
• Add a startup-only VimEnter guard (has('vim_starting')) that re-asserts the variant after the plugin's eager pass, then re-asserts the component highlights on top.

Verification

End-to-end under the real init.vim, post-VimEnter:

variant	Normal bg	background
dark	#2e3440	dark
white	#fafbfc	light
sepia	#f5f0e6	light

• 2 regression assertions added (palette ships PotionsApplyOrchid + the VimEnter re-assert).
• 270 tests pass (268 + 2).
• .version → 2.15.2, .checksums regenerated.

🤖 Generated with Claude Code