Alright, so for anyone else who comes across this issue, I believe I've found the correct solution. Annoyingly TAC has been running in circles and placing very little weight on the error messages that their own daemon is producing. The key piece of information that I was able to pick up on was the prefix of the routed error message: "KRT SEND ADD" which I realised was referring to the kernel route table. With the thought that I was dealing with a kernel issue and not a routed issue, I was able to find similar issues with other IPv6 users who were adding a high number of routes to the kernel.
I was able to confirm this by performing the following command while routed was running and attempting to add routes from the BGP session:
[Expert@gateway:0]# ip -6 route add 2001:db8::1 via 2606:1234::1
RTNETLINK answers: Cannot allocate memory
Attempting to manually add a route to the kernel produces the same error that is logged in routed_messages
Apparently the Linux kernel is shipping with a default parameter of: net.ipv6.route.max_size = 4096 which is of course far too small to fit the global v6 table (over 61,000 prefixes as of 2019). I updated the limit to match the IPv4 limit of 4194304, and now routed and my BGP session have been up for the last 48hrs with no issues.
Honestly I'm a bit surprised that something as simple a kernel parameter limit was completely unchecked by development and clearly they haven't done any real world testing of their IPv6 compatibility in this scenario as it would've been caught right away.
