HDMI output is not enabled OOTB on RPi 5? On my last test it was IIRC 
. But hotplug detection does usually not work in my case, so I need to have the screen attached before boot.
What did you do to enable video output, if it was not before?
About your actual question: The default for fsck.repair is preen, which passes the fsck -p argument instead of -y, fixing only issues which are safe to fix without potentially causing more damage/data loss: e2fsck(8) — e2fsprogs — Debian trixie — Debian Manpages
We decided to follow the conservative default instead of enforcing all repair steps, though I agree that this has downsides as well, especially if users have no other Linux system to manually check the affected drive/SD card. Like better some chance for more data loss, but a booting system, than the system not booting at all?
But it cannot be the actual bootloader, just a 2nd stage bootloader, which then IMO does not make much sense, as long as you do not require some of its facilities in particular. Especially RPi have convenient config.txt and cmdline.txt which allow altering kernel command-line parameters and firmware settings easier than GRUB does. We use GRUB where it can really act as first stage bootloader on the root drive, which is the case only for x86 systems. All ARMs and RISC-V systems I am aware of require a custom vendor bootloader (RPi), U-Boot, or EFI, and only from there GRUB can be additionally invoked, which IMO then looses its point. U-Boot can invoke more flexible own boot scripts, U-Boot and EFI can use more low-level standardized extlinux etc.
So if you want fsck.repair=yes, knowing the implications, just add it to /boot/cmdline.txt on RPi. On other ARMs it would be the extraargs line in /boot/dietpiEnv.txt, or the append line in /boot/extlinux/extlinux.conf if that one is used instead of a boot script.
Sort of annoying that there is no generic bootloader for all systems. But ARMs/RISC-V have no BIOS or UEFI, like they do no bus enumeration and hence require a device tree, so something else is needed in any case, whether we like it or not. Forcing GRUB on top of that other first level bootloader may enable a generic high level config, but also cases more complexity and overhead, more points of failure etc.