usual user

This says that the necessary short circuit was not present when the MaskRom code scanned for boot devices.
The short circuit must be ensured before the power supply is switched on, and must be maintained until a few seconds later. The procedure is a three-handed job. One hand fixes the PCB, one hand holds the tweezers, and one hand switches on the power supply.
This can only be reliably ensured with a shelf holder who uses Pogo pinns.
IMHO a bad board design for a tinker device. A push button or at least holes for a plug contact to connect a proper switch if necessary would be the better solution. Be grateful to your board designer.

Some settings that were set at build time can't be modified at runtime.
This requires a new firmware build, e.g. to set the boot delay to 0, the build configuration has to be set to "CONFIG_BOOTDELAY=0".
This is due to the build configuration. The build configuration determines the properties of a binary created from a certain source. These can be detail  settings, or even decisive for which hardware it is usable.
Finally, U-Boot can be built for all devices from the same source of a given  release version.
E.g. "make libretech-cc_defconfig" prepares a default configuration for LePotato.
You can use "make menuconfig" to fine tune it afterwards.
 
I don't know the details of Armbian's build framework, but I'm sure you can inject a patch that implements your desired change.

How to wait for a button press is outlined here.
If you want to be able to write code that is device-agnostic, you'll need to set up generic gpio-line-names.
See here for reference.
With that in place e.g.:
gpiomon --num-events=1 con1-08 && my-script will be able to run on any device that has the gpio-line-names set up in the same way.
I.e. will wait at pin 8 of the first extention connector for an event.

I'm guessing you're configuring the rc only after XWindow is already started, that way the input event device can't be added as an XWindow input device at times.
Load the rc keymap during the boot process by adding it to /etc/rc_maps.cfg.
E.g.:
* rc-empty your-config-name.toml as last line added.
 

gpiomon is your friend, e.g.:
sudo gpiomon --num-events=1 gpiochip1 97 && poweroff  

The hard work is already done, the kernel enumerates your IR device. Basically, only a suitable keymap is missing to emit the key codes you want. Each IR remote control sends different scan codes and each user expects different keycodes that are triggered at the touch of a button, so it is up to each user to create a corresponding keymap. Use ir-keytable -s rc1 -tp all from the v4l-utils ackage to determine the scan codes and assign them a keycode in e.g. a MXQ-PRO-4K.toml (man rc_keymap). If the MXQ-PRO-4K.toml located in the /etc/rc_keymaps directory is also registered in /etc/rc_maps.cfg, it will be loaded at system startup and the remote control will work out-of-the-box, e.g.:
* rc-empty MXQ-PRO-4K.toml  

I don't know Android and can't therefor help here, but I'm sure an experienced Android user can also use it to transfer an image to an sd card. However, if you are able to write an image to a USB flash drive, use a micro SD to USB adapter with a device whose system you are familiar with to write to an SD card. It is then the same procedure that you already know.

I have prepared an extlinux.conf. Mount the Armbian SD card partition and create an /extlinux directory in the root filesystem of the Armbian SD card. Then copy the attached extlinux.conf in.
Download this  kernel package and unpack it with this command in your Armbian SD card /usr/lib/modules/ branch:
tar -C ${mountpiont}/usr/lib/modules/ -xzf 5.19.0-0.rc6.46.fc34.aarch64.tgz Boot with the SD card and report if this changes anything.

IMHO I think from version 5.10.0 the path won't change again because generic node names have been around since then. Therefore, the same DTBO can always be applied. But as long as the hardware setup doesn't change, there's no reason to ever change the DTB. Therefore, after an update, restoring the DTB from a persistent location  would also be an option.
But I guess you will have more fun to keep having the boot.scr magic in place. And tinkering with boot.scr magic opens even the option to load the DTB from the persistent location direct or choose a different DTB file name that wouldn't be overwritten.