The ABI standard defines how arguments are encoded and functions are accessed in function calls on smart contracts.
The ABI standard dictates that the the constructor arguments are put on the end of the contract creation code. If you look at the init field (etherscan calls it Input Data Field in the link below) of the contract creation transaction, you will see the data that etherscan has interpreted as the constructor arguments (it is the end of the Input Data Field):
So it seems that the field called "Contract Creation Code" on etherscan does not include the constructor arguments as the text would otherwise indicate.
Digging a little deeper into the contract creation code (the Input Data field from above) reveals that the constructor arguments begin at byte 6993 (
0x1B51) of the init field. This value (1b51) also appears in the beginning of the input data field twice. I ran the binary code manually (the first 28 bytes of the init field) and found out that the bytes starting at
0x1b51 to the end of the init field are copied to memory (of the virtual machine). So the compiled code copies the constructor arguments from the init field to memory and accesses them from there in the further execution of the constructor.
You can also have a look at:
How are the arguments of the constructor encoded in the contract creation transaction?