This describes the BL1 (Silicon) to BL2 (Software) boot flow: https://docs.u-boot.org/en/latest/boar…/boot-flow.html
Once you get to BL2, what happens depends on what the software implements. Amlogic hacked in various recovery mechanisms to support common things that Android STB manufacturers want (and we abuse those to make the box run Linux). However those OEM box manufacturers sometimes tweak the code to suit their own purposes, or simply because they can, or because their developers were simply incompetent with strange ideas. As a result, while the general flow probably follows some common themes, there are enough exceptions seen "in the wild" that you shouldn't assume anything until you see UART logs and/or a dump of the u-boot env configuration.
If vendor u-boot is on eMMC in 99.999% of boxes it will be used. The contents of the u-boot environment (env) will then dictate what happens next. If the env has been modified through boot.scr or s905_autoscript methods it will look for Linux boot files (as dictated by what the boot scripts set) and this remains configured unless a reset is performed (restoring the original env for Android-only boot) or the recovery mode is triggered again; causing it to look for boot.scr or s905_autoscript which can (re)modify the env again.
Your box has an env modified by CE boot scripts to look-for and use CE boot files. Unless you trigger recovery again and tell it to use LE boot files; it continues to look for CE files and fails to find them as CE and LE boot media are (intentionally) different and since the kernels are now also rather different, the boot params may or may not be aligned.
Users frequently assume u-boot scripts are read on every boot and this is not true. Users also assume they can rename files and make it all work, and this is not completely true. Users also very-very-wrongly assume that I have any interest in CE or interest in triaging frankenbox configurations. Sorry to dissapoint..