During the contract construction an event was emitted that informed Etherscan of the minting:


    // Constructor
    constructor() public {
        ...
        balanceOf[address(this)] = totalSupply;
        emit Transfer(burnAddress, address(this), totalSupply);                             // Mint the total supply to this address
        ...
    }


The contract increments its balance to the totalSupply (which is 1m) and the transfer event is done in order for Etherscan to *track* the creation of the asset and increase the balance accordingly.

The burnAddress was used to simulate the creation of Vether, because that is where all the Ether is burnt:


// Calls when sending Ether
    receive() external payable {
        burnAddress.call.value(msg.value)("");                                              // Burn ether
        _recordBurn(msg.sender, msg.sender, currentEra, currentDay, msg.value);             // Record Burn
    }


This is typically how new dynamically created assets are minted and destroyed, except address(0) is used:

https://etherscan.io/address/0x0000000000000000000000000000000000000000

====================

However, Uniswap forbids sending assets to the address(0):

https://github.com/Uniswap/uniswap-v1/blob/master/contracts/uniswap_exchange.vy#L163

So another address must be used. This address is the binary encoding of the word `value`, which you can verify for yourself at:

https://www.rapidtables.com/convert/number/ascii-to-binary.html

The likelihood that someone has the private key to this address is the same likelihood of someone having the private key to address(0), since they are both valid Ethereum addresses.

Mathematically it is 1 in 2*256-1, of which there aren't even enough atoms in our universe to count this. This video covers this:
https://www.youtube.com/watch?v=bBC-nXj3Ng4


====================

I hope that addresses your concerns.