The ZeroExVotes implementation is working via a vanilla openzeppelin ERC1967Proxy implementation and is upgradable that way while its proxy address remains immutable. The wrapped token itself on another hand is non-upgradable by design.
Note that although in openzeppelin’s ERC20Votes implementation for example the token and the voting logic are part of the same contract, we decided on a different design that abstracts the voting logic away from the token. This approach was discussed with openzeppelin here Quadratic voting - Contracts - OpenZeppelin Forum
The above discussion also holds the explanation as to why a reference to the voting contract - ZeroExVotes is named _token which is to emphasize compatibility with GovernorVotes implementation of openzeppelin but I do accept it’s confusing and have just pushed a rename of that.
On code coverage we do not use typescript for testing but do use coveralls and foundry and coverage is currently at >95% for contracts see latest report at 0xProject/protocol | Build #4425512986 | Coveralls - Test Coverage History & Statistics