The log seems to properly indicate the 5 second delay in the difference of timestamps.
You won’t see a message at the actual time of transmission appearing in the packet forwarder log, because the timing of the transmission is done by a counter in the hardware of the SX130x chip that counts up to the programmed packet time. At most, in some later generation packet forwarder programs you might get a message when a packet is moved from a software “jit queue” to the single-packet hardware buffer (which would happen when it becomes clear that nothing else can need to go out first) but not necessarily. Simpler/older versions of the forwarder code just load packets into the hardware immediately as they are received over the backhaul without implementing a software queue to re-sort them in order of actual transmit time. That really only makes a difference in the case where you have something like a normal 1-second uplink/downlink cycle from a different node popping up in the middle of a 5-second join/accept cycle, which is not happening here.
If you want to really see what is going on, see if you can get a scope probe on the gateway transmit LED and modify your node firmware to blip a GPIO at the start and end of the uplink packet and receive window. Trigger on the node transmission and then see where the gateway activity falls on the other scope channel, and then where the node’s receive window is falling relative to that.
I’d suspect though that the problem is either receive window timing on the node end, or a mismatch of identity/key causing the node to be unable to use a response if it is actually receiving one.