While a packet forwarder typically consumes the GPS serial (or in some cases possibly I2C to leave the serial free for other use) output directly, it doesn’t really need to - the precise timing is accomplished by the concentrator chip itself recording the PPS signal against its internal timer, the serial message in then parsed to determine which second that was. So a slight delay from doing something like consuming the message with something else and then passing it over on a local or unix socket or pipe should probably not be an issue.
It’s not clear if your ntp scheme needs the PPS signal. If it does some electrical re-routing may be needed. Once you are doing that, running the serial signal to two UARTs could be a possibility, though if you are on a pi you really only have one - using a USB serial device is likely to introduce more latency than a reasonable software sharing scheme would.
For that matter, it may be worth considering if having the GPS referenced timestamps for the LoRaWAN gateway functionality is really accomplishing all that much for you - especially in the case where you can get a fairly correct system time. It’s possible that the simplest solution could be to modify the packet forwarder to not open the GPS port and not be GPS referenced, and let the ntp own it instead.