netstat doesn't indicate that anything is listening on port 1433, that leaves the possibility that a client is already using port 1433 when SQL tries to start. From the SQL Server Premier Field Engineer blog post about "TCP Port is already In Use":
The second situation involves a client running on the server using the same dynamic port as SQL Server. Every TCP session requires two endpoints – a client endpoint and a server endpoint. Each endpoint is an IP Address/Port combination - also known as a TCP socket. Normally, the client socket code will ask the OS to provide a port from a range of dynamic ports. The server socket is the IP/TCP port of the service the client is connecting to (SQL Server for example).
The default dynamic port range might include port 1433. You can check it with
netsh int ipv4 show dynamicportrange tcp.
...if you happen to have a client (think Windows OS system services) that starts BEFORE SQL Server does, it could use TCP/1433 for its client socket.
So, how do you fix and prevent a situation like this? There's another feature within the OS that allows you to tell the OS the TCP ports in the Dynamic Port Range that should be EXCLUDED. All that is needed is to run the following with an Administrative Command Prompt:
netsh int ipv4 add excludedportrange tcp startport=1433 numberofports=1 store=persistent
After that setting is made, the OS will not give any clients that port. Services can listen on it still, but you prevent clients from getting it when asking the OS for a dynamic port.
The original poster indicated that even though the logged error mentioned IPv6, his problem turned out to be with IPv4. But if it had been an IPv6 port conflict, the same process can be followed for IPv6.
netsh int ipv6 show dynamicportrange tcp
netsh int ipv6 add excludedportrange tcp startport=1433 numberofports=1 store=persistent