Bug report: AES-CTR does not appear to work correctly in CyberChef when the algorithm counter rollover occurs.

**Describe the bug**
When attempting to rollover the counter for AES in CTR mode, the CyberChef output is different from Open-SSL and Crypto++.

**To Reproduce**
Steps to reproduce the behaviour or a link to the recipe / input used to cause the bug:

In CyberChef, set up for AES Encrypt: https://gchq.github.io/CyberChef/#recipe=AES_Encrypt(%7B'option':'Hex','string':'000102030405060708090a0b0c0d0e0f'%7D,%7B'option':'Hex','string':'ffffffffffffffffffffffffffffffff'%7D,'CTR','Hex','Hex',%7B'option':'Hex','string':''%7D)&input=ODg5OWFhYmJjY2RkZWVmZjAwMTEyMjMzNDQ1NTY2NzdmZQ

Use the following inputs:
Key (128-bit): 000102030405060708090a0b0c0d0e0f
IV (128-bit): ffffffffffffffffffffffffffffffff
Plain Text: 8899aabbccddeeff0011223344556677**fe**

CyberChef result: b4ddb58902da6cdc64c680aa4a05dd64**01**

**Expected behaviour**
I expected the Crypto++/Open-SSL result in CyberChef: B4DDB58902DA6CDC64C680AA4A05DD64**38**

**Screenshots**

**Desktop (if relevant, please complete the following information):**
- OS: Windows 11
- Browser: Microsoft Edge, Version 123.0.2420.97 (Official build) (64-bit)
- CyberChef version: 10.17.0

**Additional context**
This was tested against two other models (one for a HW implementation). Both models agree with Crypto++ and Open-SSL