The largest power consumer should be the LoRa concentrator card’s baseband processor chip, you basically need that any time you want to be a gateway, though the power consumption does drastically reduce when it is not being operated by the packet forwarder software.
The MT7628 processor doesn’t really have sleep modes; you may with a lot of effort be able to reduce the clock, but that’s going to be a quite advanced topic far beyond simply building OpenWRT from source. Fortunately the MT7628 doesn’t consume all that much power, probably less than the concentrator card. It’s probably worth figuring out how to make sure that the wifi radio is off, and not active but simply being ignored - I’ve seen MT76x8 projects used with an insufficient power supply brown out at precisely the point in boot where the wifi kernel module is loaded.
In terms of LTE, while software should indeed be able to turn this on and off, doing so is fairly incompatible with running LoRaWAN to an external server. LoRaWAN is a protocol that assumes that any response needed by a node can completer a roundtrip of node - gateway - server - gateway - node in a small amount of time (by default just 1 second). Obviously this won’t work if you keep turning the connection between the gateway and the server on and off.
There are two strategies you could consider:
Go ahead and turn off the LTE backhaul, make sure the packet forwarder doesn’t stop on loss of acks, collect received packets locally, and accept that this means nodes will be operating open-loop with no way to receive replies even for purposes such as adaptive data rate (ADR)
Run the server (perhaps the packaged LoRaServer) on the gateway itself, and only report results over LTE occasionally. This has two issues: first, you can only have on gateway in a geographic area, or at least only one can be authorized to transmit to nodes - to avoid collisions on the air, any additional gateways would have to be rigged to only collect packets, and never autonomously reply. Next, you’d be imposing a latency in reporting the data to anyone interested, though you could write rules to wake up the LTE when there is something “interesting” to report.
Also worth noting that by specification LoRaWAN packets have a frame counter, and server will reject packets with out of order frame count. So if you try to inject some packets received in the past into a server at a later time, if it has received any more recent packets (either from another gateway, or current packets from this gateway intermixed with stale packets being replayed from storage), then the packets with out of order timestamp will be silently dropped.