There are multiple questions involved and without a specific project I can only give general hints. It needs a system architect with an understanding of workflows, data structures, business processes and the details of the tools described below to create a reliable system with this.
Offline Synchronization
The QFieldSync plugin takes offline copies of features from any kind of feature source, e.g. a postgis database. This source will have a copy of every feature in the database and create logging tables. Every change on this offline data will also create an additional entry in the log tables if it's done in QGIS or QField. When the data is synchronized back it will replay all these changes on the main data source (e.g. the postis database). This functionality is leveraged by QFieldSync from a QGIS builtin functionality "offline editing" which is also available through the core offline editing plugin.
If something does not work as expected here, it's often most interesting to check the log tables in the geopackage (e.g. using the db manager in QGIS). If they do not exist, something went wrong with creating the offline version. If they do not contain anything, the edits have been done in an environment which did not have offline editing enabled.
Audit trail
When synchronizing the data back into the main database, there needs to be some link to the user who edited this data. There are several possibilities how to accomplish this:
Use a field with a default value like @user_full_name. This is updated by QGIS/QField and can optionally be flagged with "update on edit" to fill a "last_changed_by" column. This relies on changes being done in an environment that supports QGIS Expressions and you need to trust your users that they don't fake this information. Furthermore you also get the information who changed this last and not a full history of your data.
Use a field on the database and fill it with a trigger. Postgres can update fields on update. See this answer on how to do it for a timestamp and expand this to include CURRENT_USER which is the user which is executing the SQL. This requires that you have setup your database for multiple users and that everyone logs in/runs the synchronisation with his own account. The same restrictions on missing history apply (but can be solved with more triggers)
Another possibility is to use audit triggers in your database, this will offer a complete postgres-database based solution.
I don't think the geopackage spec is relevant here, nor do I have experience with the postgis history tracking that is linked in the question.
