I think the linked thread shows some of the complexity of the issue, with a much more detailed technical explanation. (I did not fully check the detail, but I thought there was a high chance you were in a similar position although detail of your case is different).
Loosely speaking, I believe evolving technology is causing carriers to make changes to APN more often than previously. I think that with the cooperation of Google these changes can now be made on the fly, but at the moment it seems from cases reported like yours and the linked thread that part does not happen in /e/OS. /s/OS, being AOSP, gets its APN in the way described more fully below.
This is mostly a response to “it doesn’t happen on my regular Google phone” – the main part of your post, as I read it 
I find this argument hard to answer because I just don’t want a system owned by an advertising agency running my phone. I will do any amount of adjustments that are required – as the /e/ solution seems easier than a Pinephone and cheaper than Librem.
So, as @cornfarmer found, a call to the carrier may be the answer. As the simple response.
I had not covered this part of your question.
It seems the case that on an update (some or all phones ? * ) receive an update of the /e/ “catalogue” of APN. Here is the link at branch v-1-s https://gitlab.e.foundation/e/os/android_vendor_lineage/-/blob/v1-s/prebuilt/common/etc/apns-conf.xml?ref_type=heads. That is current.
Study of the commit history https://gitlab.e.foundation/e/os/android_vendor_lineage/-/commits/v1-s?ref_type=heads would reveal if a change, in the case of your carrier, had happened since the date of your e-1.11-s build.
And / or I am not clear if perhaps you felt an edit you made to your APN was overwritten by the update?
When one knows a supplied APN is wrong it might be better to Add your corrected APN, in case it could happen than an APN (Edited by a user) is overwritten by an update.
Edit With the timing of your
- install,
- adding APN,
- update to 1.12.3
I see that this is probably not advice pertinent to your situation, more general advice ! 
* Edit 2. I used to think that update of apns-conf.xml happened at Android version upgrade. It looks from recent activity that apns-conf.xml may be updated at every update – would anyone confirm this.
Edit 3
In your Mint “advised” APN link we see
MCC – (do not change default values)
MNC – (do not change default values)
MMSC – http://wholesale.mmsmvno.com/mms/wapenc
in apns-conf.xml, mmsc="http://wholesale.mmsmvno.com/mms/wapenc" occurs < 10 times, but I do not see it associated with what I recognise as the T-mobile mcc which I thought was "204"
@roadrunner4spd, to help to see if there is a case that we should submit a request to add or change any T-mobile entry in apns-conf.xml please can you confirm the
mcc="xxx" mnc="xxx"
you use.
For further reference https://source.android.com/docs/core/connect/update This demonstrates the method of update of APN in AOSP – which is implied different from the method used in a Google phone (as “on the fly”)
