this worked! thank you so so much!

A shutdown cause of -20 means that the T2 chip, which is the hardware root device for the 16" MBP and is an essential component in its operation, has detected that certain critical processes on it have hung and there is no safe way to continue running while maintaining data coherency, so the only option left is to shut the system down.

By definition, any action on the part of the user which induces this behavior is considered to be a bug in the operating system. Regardless of any bad user actions or badly designed hardware or software, the OS must always be resilient and fail gracefully. A shutdown or reboot here means that you have found, at minimum, a bug in macOS (or, probably more likely, bridgeOS), and possibly also a bug in the ThinkPad.

Apple has a longstanding history of latent bugs being exposed by faulty peripherals and you are stumbling into yet-another of these. At the end of the day, because you are not an Apple engineer with access to their source code and debugging tools, you will never find and fix the root cause yourself. So the one thing to always do in these situations is to report the bug to Apple (links one and two). Please do this first so that they are able to collect failed-state data from you.

Then, until this bug is fixed and an update issued, your next step is to find a workaround. A few things come to mind:

1. Obviously, you can try to avoid using the ThinkPad, but this doesn't really count as a workaround.
2. Update to the latest macOS, which you have already done.
3. Can you try attaching to the USB-C ports on the other side of the MBP? There is an actual hardware difference in the signal path between the left and right sides which occasionally makes a difference for these kinds of bugs.
4. Can you try attaching through another device (like a USB hub) rather than directly into your MBP?
5. If this is the result of a software race condition, we can fiddle with a few big hammers. One is to temporarily disable CPU C-states. Note that this will dramatically increase power consumption so you should reenable them after testing. The procedure is to add the cstates=0 argument to your boot-args. (If you're not familiar: First disable SIP, reboot back into normal macOS, and run sudo nvram boot-args="cstates=0", making sure that you're using straight quotes by copy-pasting rather than entering smart/curly quotes. Reboot and now you're running with C-states disabled. See if this problem goes away or not. If so, it's valuable info to pass on to Apple. To undo, run sudo nvram -d boot-args and reboot; you can turn SIP back off at that point.)
6. Similar to the above but having a more dramatic effect on performance: You can temporarily run in a single-threaded CPU mode. Same procedure as #5 except instead of cstates=0 you would put cpus=1. You will really feel the effects of this as everything will be slower. But it's a good test to try.