The reason you can’t find a DIO mapping probably has to do with the fact that the board’s schematic ButtonSizeNode3/BS3_schematic.pdf at master · EasySensors/ButtonSizeNode3 · GitHub shows it to be missing a connection critically needed for the operation of usual LoRaWAN firmwares.
DIO0 is connected to a signal called RFM_INT which appears to run to Arduino Digital Pin 2. This would be the first element of your LMiC pin mapping, and is used to detect the end of a transmission against which the receive windows are scheduled, and also to detect the end of a successful downlink (including join accept) reception.
The problem is that DIO1 is unconnected. On the sx127x radio (aka RFM95/96) DIO1 is used to indicate that the receiver has timed out and not received a signal in the configured listening period or “window” - and since LoRaWAN is “uplink mostly” apart from join accepts and initial configuration, that would be the case the majority of the time. The popular “Feather M0 LoRA” board is also missing this signal, but happens to run the radio pin to a board header, where users can easily double it back to an MCU GPIO pin that they enter in the pinmap.
Your board doesn’t appear to run the radio pin to a header, but the connections on the radio module itself are reasonably sized (2mm pitch I believe) so you can probably with some care solder a wire from the DIO1 pin to an unused digital pin you enter in your pinmap - D4 would be a logical choice but actually any pin will work.
If you can’t add the wire, things get more complicated. In theory one can rework LMiC so that instead of relying on the signal, the processor uses the SPI to poll the radio status. The radio can either still be programmed with a finite listen window and polling used to see if has timed out. Or the radio can be put in eternal receiver mode, software can wait an appropriate window time and check the radio status. Since the window time is only the battery to be spent seeing if a packet begins, in purely software timed mode, software would have to distinguish between the case where the radio has found nothing, in which case it can be put back into the lowest power mode, or the case where it has started receiving a packet and will need hundreds of milliseconds more operating time to receive the entirety of it before the end is signaled by the DIO0 pin or status register change. Even with a full pin mapping, I think it’s arguably worth giving the radio code an ultimate software time limit. Also it would be nice if LMiC complained about ineffective pin maps, but that would run counter to the need to keep things small for an ATmega328p - especially the space taken by the strings to be printed!
So the summary here is that this board was not designed by someone with a lot of familiarity actually using LoRaWAN in accordance with the spec. The example code is incomplete, and appears even with the missing pieces to be doing point-to-point LoRa rather than LoRaWAN. You can make it work for LoRaWAN, by using an optimal build of the latest LMiC that will fit in the chip resources, and adding the missing DIO1 connection. Or at a more advanced level, reworking the radio management code in LMiC. But overall, this is not a friendly platform or a very straightforward place to be starting your exploration of LoRaWAN. For that something like the traditional Adafruit Feather M0 with the frequency appropriate LoRa radio (not the FSK-only RFM69!), or low power sleep complications aside, an ESP32, probably make more sense especially as there are far more people working with them.