admin_audit does not log userid for trashbin background job remove events

When the background job OCA\Files_Trashbin\BackgroundJob\ExpireTrash removes objects, it currently logs messages such as:
File "/files_trashbin/files//Testfile.d1756234730" deleted from trash bin.

Since these deletions are executed automatically by the system and not triggered by a specific user, the "user" log field remains empty. As a result, it’s unclear to which user the deleted trashbin file belonged.

I would like to propose a change that:

• Sets the userid field accordingly and extends the log message to explicitly indicate that the deletion was triggered by the background job. For example:
  File "/files_trashbin/files//Testfile.d1756234730" deleted from trash bin (triggered by background job).
  This approach is likely beneficial when all Nextcloud logs are forwarded to a central logging system and correlated, as in our case.
  However, if the admin_audit design prefers to write to the user field only when actions are directly performed by a user, I completely understand that decision.
• Or, writes the user ID associated with each deletion into the log message and/or another dedicated log field.

Additionally, it would be very helpful to log the affected object ID when using S3 as the primary backend. For my purposes, having the object ID readily available would facilitate correlation, especially since, a correlation was only possible through a Nextcloud database restore prior to the object deletion for me.

Start with OCA\Files_Trashbin\BackgroundJob\ExpireTrash and trace how its removals are recorded by admin_audit. Review the trashbin user association and S3 deletion context described in the issue, then determine which logging approach fits the project. Done means the affected user and, where available, object identifier can be correlated in the resulting audit event.