Hi Thomas,
I think the combination you're trying to build just doesn't work and isn't really supposed to work, honestly. Unfortunately, the current state of those Kconfig options was implemented by contributors who weren't the primary vboot developers and pushed through somewhat hastily without really working out what option combinations make sense. There have been a couple of discussions about how this should be changed for the better (although I can't really find them anymore right now, some random Gerrit CLs two years ago) but I think basically it's just been stuck like this for a while with nobody having the time or pressure to clean things up.
vboot was originally designed to be used with VBOOT_SLOTS_RW_AB, that's the most supported and most tested mode. I guess running it with VBOOT_SLOTS_RW_A should also work, although some of the internal logic is going to get a bit confused about the missing slot B, but eventually it should end up falling into the correct high-level behavior (that when slot A is broken, it falls into recovery mode). But building vboot without any RW slots makes no sense: the whole point of vboot is to verify RW slots. Without RW slots you don't need vboot. If your whole flash is write-protected (and therefore trusted) anyway, there's no reason to cryptographically verify any of it on boot.
The third combination that would actually make sense is to have one RW slot but to have no recovery mode fallback in the RO_SECTION. That would be what you want for the tiniest possible flash usage, basically (accepting the risk that if the RW_A section becomes corrupted your device would just be a brick). But that combination is currently not implemented.