The issue you reference has nothing to the .NET server. It has no way to return a user-agent string for a browser. The user-agent string is set by a browser only. But your string was changed. Checked now Chrome (v95 x64), Opera (on Chromium v94 x64), Edge (v95 x64), and FireFox (v94 x64). For a redirecting link, I used HTTP://google.com (yes, not HTTPS - to get the HTTPS redirect as 307 Inner redirect). All initial user-agents for speed and unification were set to the same 'iPhone 5/SE'. My results are below.

Chrome.

HTTP request goes as phone Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/603.1.30 (KHTML, like Gecko) Version/10.0 Mobile/14E304 Safari/602.1.

HTTPS goes as Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36. User-agent changed. Issue. The same case you highlighted.

Opera (almost, another Chrome version). HTTP request goes as phone. HTTPS goes as phone. No user-agent change. All works as expected.

Edge (almost, the same Chrome version). The same case as on Chrome. Ding!

FireFox (different engine). HTTP doesn't go - HTTP/3 in use that starts with HTTPS initially. Not an example here.

There is a similar issue in a Chromium bug list. But it is not like yours. https://bugs.chromium.org/p/chromium/issues/detail?id=1234461&q=User-agent%20string&can=2

Anyway, it looks like you found a Chromium issue on v95.

My greetings! It's your right to report the issue.

As an option, it is possible to use new User-Agent Client Hints headers Sec-CH-UA* on server: Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform. But these extensions are new. Most mass modern browsers are using it but not Firefox or Safari. Just set up your server to request them. If the UA string is in use at a client, that it is better to get proper values via JS: navigator.userAgent, navigator.appVersion, and navigator.platform.

It is planned to get rid of already not clear UA string in the future.