Value of “counter” when decrypting AES in CTR mode?
With a 4 byte counter, it is a representation of a 32-bit unsigned integer. Since the counter increments from 0, there is no need to store it on a per message basis. This then becomes an implementation issue.

A smart AES-CTR implementation would accept ANY initial counter/nonce value, and simply 0-pad it to the desired length. If we supply the cipher only 12 bytes, it would be starting with an initial counter of 0. If we supply 16 bytes, the last 4 would be the start counter (which could be 0).

For storage and transmission of the data stream is outside the scope of the cipher, and the length of IV is up to the implementer. Applications that require a new key for each message may not even store the nonce, and instead start from an all 0 IV every time. 4 bytes is not a lot, so if storage is available, storing the entire 16B counter/nonce value would probably make the most sense. I would assume the majority of applications looking for compatibility would store the whole thing, while those that use a fixed nonce length and do not require compatibility store only the nonce.

Any application that stores the counter along with the nonce would store it in a manner where it would be correct for the first ciphertext block (block 0), it would not store the last counter used during encryption (block n). Hence the term, initial value. During decryption, the keystream generation is seekable by supplying the required block number as the initial counter of the IV.