With AES-CTR does the block input need to be implemented as nonce || counter? I am looking at an AES-CTR implementation (WebCrypto) and it takes an initialization parameter count which is an array of 16 bytes. It then asks you to specify length, or how many bits are dedicated to the counter (the rest will act as a nonce.) So if you specify e.g. length = 32 the block input will be nonce (96-bit) || counter (32-bit). It then says that the counter should be large enough that it does NOT wrap.
My question is why not just use the full 128-bits as a nonce AND counter. Initialize it with a random 128-bit value and increment the whole thing and as long as you don't wrap all the way to where you began then everything is fine.
https://developer.mozilla.org/en-US/docs/Web/API/AesCtrParams#Properties
Usually a 128 bit counter is implemented, and the 16 byte IV is really just the initial counter value, consisting of the nonce and a counter. The counter is generally an unsigned value. So your scheme is very possible, but other implementations may make other choices (and if you look at NIST SP 38A, Appendix B, about any scheme suffices).
The fully random IV scheme however has a problem. You never know how close the initial random value is to another initial random value. The chance of two counters out of $N$ counters being close to each other quickly increases with the number of IV's generated.
If you have a incrementing part consisting of $l$ bits then you can have $2^l$ separate counter values before you may run into a collision. There is still a birthday problem, but it is now at least quantifiable, and it's only an issue for the nonce, not for the entire counter. Furthermore, you know exactly how large your message may be.
Let's create an example, which one would you rather have of these initial IV's?
Fully randomized:
27df9ad9921861c7 b53ab03a aad9bf3f
27df9ad9921861c8 dca9d07a 2f50dc18

or nonce || iteration counter:
27df9ad9921861c7 b53ab03a 00000000
27df9ad9921861c8 dca9d07a 00000000

On the first you've got a random amount of counters for each message (in this case 0x84771CD9 or 2,222,398,681), for the second you've got exactly $2^{32}$ counters. Worse, in the first case you don't exactly know how much space you have, because you're not going to store the random values.
The fully random scheme is also somewhat slower as it requires more random bytes. It also requires careful handling of overflows, as you don't want to have an issue after you hit FFFFFFFF.
In short, if the random scheme has any advantage then I'm missing it; I would strongly recommend keeping to a concatenated nonce and counter as input block.