That’s not how LoRaWAN works: devices do not “connect” to a gateway. Instead, once they get some secrets by activating on the network through one or more gateways, they simply just transmit when they want, and hope that the same or other gateways will receive their transmissions and forward their data to TTN.
However, with ADR enabled and sending every minute, then if the only gateway around was offline for a longer time, chances are that the device detected that its transmissions may have gone missing quite soon. For ADR, it will then have lowered its data rate step by step, until hitting DR0 (SF12 BW125). If not getting ADR responses at SF12 either, then at that point a device could choose to start a new OTAA join. But many devices don’t as it it’s not likely to help at all. Maybe BEEP’s source code can reveal more.
Assuming the device would just be stuck at SF12, the gateway should receive its packets once powered on again (without the need for a new OTAA join), and ADR should help the device to get to a better data rate again.
Indeed, TTN only forwards the data to the application that owns the device. (So, the one for which the settings in TTN Console match those in the device.) I’d assume you should copy and safely store the existing AppEUI and AppKey if visible in the app, and could restore those any time you like. But I don’t know.
Then apparently the reception quality was okay at that time?