Only that SQLite, and by extension the Geopackage format, doesn’t give you a built-in way of obfuscating the data inside the file. You might come up with a way to encrypt some of the data, although I don’t think you could encrypt the geographical data without breaking compatibility (the actual position of the points and vertices). And in any case, this would be entirely on your end (It is strongly ill advised to create custom ad-hoc solutions for cyber security, always try to reach for established and battle tested solutions).
As is, any person with the file would have access to all the data in the Geopackage, while an account to a PostGIS database can be limited to only specific tables and rows.
You have to first configure a text field/attribute on a layer to have a widget of the corresponding type, for example the type “Date/time” for the Datetime field. This is done typically on QGIS:
That’s typically all you need to do. Both QGIS and QField will read this information and present to you a Form which includes a field with a date value that even pops a calendar to help you choose (the following is a capture from QGIS):
This form pops up every time you add a feature on a layer (which is the pretty much the same as saying a “record” on the database) or when you edit an existing feature. When you press OK on the form, at least on QField, the data will be automatically saved, no need for any additional action (that is, if a user then directly goes to upload the project, it will go with this change made).
The way I think of it, ‘versioning’ would be handled by showing only the latest record associated with an entity. On your database/file you’ll have each and every version, since you wouldn’t delete or modify the older ones, but rather only add a new one. You’ll need to provide a way to identify the same entity in different times (typically, an ID field), but between the Filter function (check this tutorial to get an idea) and the previously mentioned time series functionality, QGIS can help you visualise only the “last” or “correct” version of the objects.
How I imagine and suggested, each time you conduct a survey (regardless if it’s the first time for that particular object or site, or if it’s just a revision) on QField you would add a new feature/record (on QField, this typically means pressing a green plus button on the bottom of the screen) to the same and single layer for that type of object. For example, if you have a “building” layer, adding a new real actual building to the table/layer would use the exact same workflow as just conducting an inspection to an already added building. Because the “building” layer would actually be a “building survey” layer and each record would be “stateless” (would not need to know the state of any previous record on the layer), so it doesn’t matter if it’s the first on 126th time you survey that particular building.
You can then have a Filter on that very layer that (using an Expression) checks for the latest value for each particular “entity” (for each ID in that table) and only shows that as a point in the map. You can even hide the datetime field from the surveyor and make QField add the current datetime automatically into that field, saving time for the surveyor and making your data less error prone.