This all sounded great but it led to a lot of problems.
If anyone else is embarking on this journey, this is the crucial part which was missing: Using EEPROM — Kaleidoscope documentation
As far as I now understand it, if you have already used Chrysalis, which edits configuration stored in the EEPROM, flashing a new firmware (even the default one, it seems), garbles it. (Or rather, the storage space has now moved.)
I hadn’t saved out a backup, so I now have to configure from scratch again.
I do not currently understand how Chrysalis and the EEPROM are supposed to exist in the same workflow as custom firmwares. If I’m doing anything at all in Chrysalis, it appears that I need to rigorously keep my settings backed up, and every time I flash a new firmware (which is a lot while I’m iterating on it or some plugin I might be writing) I need to then close the IDE, open Chrysalis, unplug and replug the keyboard, connect, restore my backup, and save it.
I understand now that the keymaps saved via Chrysalis are totally separate from the keymaps set up by the firmware, and that a firmware plugin will automatically switch to a Chrysalis layout if one exists. If you reset the EEPROM via Chrysalis, it seems it does set a layout in EEPROM, so the layout you set in firmware is still ignored.
I tried resetting the EEPROM to default again after flashing my custom firmware, and then after unplugging/replugging and connecting via Chrysalis again, I now finally saw my firmware-configured Dvorak layout. It’s not clear to me whether this was copied to Chrysalis/EEPROM or what. But I decided at that point to ditch Chrysalis and go back to doing everything in firmware.
I had to disable various plugins so it won’t try to load a layout from EEPROM.
I now have the LED effect I wanted, so I suppose I’ve achieved my goal, but it was anything but simple.