I would like to add that Let's Encrypt intentionally randomized which intermediate leaf certificates get issued from to discourage intermediate pinning, or systems relying on leaf certificated being issued from a specific intermediate.
bLink also seems unaware that Let's Encrypt always keeps backup intermediates which are in stand-by to take place of the active intermediates in events like compromises of the active intermediates. Because of this, LE specifically states they might start issuing from the backup intermediates with little to no notice.
bLink failing to update their website for almost a year tp reflect the changes in LE's issuance hierarchy is another example of why enforcing specific intermediates be used is a bad idea. Their policies should only include requirements users are able to affect (like the roots, key types and EKUs).
The Google Chrome root program made changes that forbids CA's issuing publicly trusted certs for both server and client authentication if they want to continue to be trusted by Google Chrome. This policy affects all CAs, and no CA on their list will be able to offer certs that are both server and client auth after July 2026. As mentioned above, private CAs are much better suited for client authentication.
For now, the best you can do is running certbot with the --key-type rsa --rsa-key-size 3072 --required-profile tlsclient
It will not use the intermediates specified in their docs, but their docs are asking for a hierarchy that's long been retired, and this will be the closest you can get. The last day you will be able to request a client auth certificate from Let's Encrypt will be July 7th 2026, and it will remain valid until October 6th 2026. Beyond that date, neither LE, or any other CA on their list will provide publicly trusted certs with the ClientAuth EKU.
I would recommend making their support aware of this forum thread, since it includes links to all the resources they might need to understand the situation.
Hope this helps.