According to what I've read, a local SQL account must exist on the SQL server with sysadmin rights
Aside from the original efforts to actually install SQL Server on that machine (which does require some type of account with local Administrator rights, and that account will automatically be granted membership in the 'sysadmin' Server Role), Patch Manager has no interest in LOCAL accounts on the SQL Server system. If you've read something that says Patch Manager requires a local account with membership in the 'sysadmin' Server Role, I'd be interested in reviewing that information.
and a domain account needs to exist with sysadmin rights in the SQL server.
Correct. This account is required to allow the initial Patch Manager database to be created, as well as certain least-privilege user accounts. Once the database and database user accounts are created, the domain account is no longer used.
The domain account is in a different domain, however a 2-way trust exists
I would suggest verifying that this bi-directional domain trust is functioning as it should be. The "user does not have privileges" exists either because that domain account is not a member of the 'sysadmin' Server Role, or because it's unable to properly authenticate the account.
I logged in as the service account that has sa rights to the SQL box
Patch Manager also does not care about the sa account (which, by all rights, shouldn't even exist on a remote SQL Server instance installed for use by Patch Manager), unless by "sa rights" you mean the domain account that is a member of the 'sysadmin' Server Role.
Is it common to have this installed in a Server 2012 environment?
We have several customers who have installed Patch Manager onto Windows Server 2012; however, a much smaller group who have found it necessary to use a remote SQL Server. Using a remote SQL Server has been a feature since Summer, 2011, and we've experienced very few issues with the installation in this environment.