LUKS doesn't have keymaps. It doesn't read keyboard input on its own – it's just a generic console program that reads console text input, leaving it to the console to map the keys.
Various solutions (example 1, example 2) recommend to edit /etc/vconsole.conf, but this file is not present on my installation
That's usually normal. Not all configuration files are present on every installation. Indeed a big part of systemd's overall design is that no "default" or "template" configs should be present in /etc, with everything static being in /usr/lib instead. (Many other projects have since followed that convention.) So the absence of a config file is not an indicator that the system won't use the file, and should not stop you from creating it if you know that the system does use it.
(On the other hand, as in many thing systemd, it does have an alternative: the vconsole.keymap= kernel command-line option mentioned in the vconsole.conf manual page, which – if your system was using systemd-vconsole for this – you could add to your GRUB configuration.)
That being said, I don't think Debian actually uses systemd-vconsole at all; not even for the main (rootfs) boot. (And the initramfs is a whole separate world of its own, having its own config files and everything. As mentioned in the comments, initramfs building varies greatly between distributions – Debian uses its own "initramfs-tools" to do so, while other distributions may use Dracut, mkinitcpio, Booster, genkernel, and so on.)
So in your case, the Ubuntu instructions for /etc/initramfs-tools/initramfs.conf are the most suitable for Debian's initramfs as well.
I would prefer to first understand which keymap is active now.
Unpacking the initramfs (it is a mini-rootfs in a cpio archive) with lsinitramfs or cpio or bsdtar might reveal what keymap files, if any, are embedded in it. Enabling verbose mode when the initramfs is being built, with update-initramfs -u -v, may also reveal it.
But in Debian's case, unfortunately a generic file name seems to be used – it just takes whatever "cached" keymap was present in the main system when the initramfs was built. All it reveals is whether there is a keymap in the initramfs, or not.
So if you just built a fresh initramfs, it should be safe to assume that it will either use whatever console keymap has been configured via /etc/default/keyboard (if the KEYMAP=y option has been enabled in initramfs.conf), or the generic built-in 'us' keymap (if it hasn't been enabled). For example, this shows that the system keymap has been copied into the initramfs:
# update-initramfs -u -v Calling hook keymap Adding binary /usr/bin/kbd_mode Adding binary /usr/bin/loadkeys # lsinitramfs /boot/initrd.img-6.1.0-12-amd64 | grep kmap etc/console-setup/cached_UTF-8_del.kmap # bsdtar -tf /boot/initrd.img-6.1.0-12-amd64 | grep kmap etc/console-setup/cached_UTF-8_del.kmap
Finally, interrupting your initramfs with a kernel option such as break=premount should give you a shell at the correct point in time (after loading the keymap but before the LUKS prompt) where you could press keys and see what gets typed.
update-initramfs. I was not aware that other distros had other tools for this task, thanks.