[Bug]: E-mail notification for activity (public_links_upload) doesn't respect the activity_setting_batchtime

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

I've upgraded from 29.12 to 30.08 and now all the users keep receiving the activity emails every hour for the "public_links_upload" amq type even if the activity_setting_batchtime is set to daily. All the others amq type are unaffected and respect the 24 hours batchtime.

Steps to reproduce

1. Share folder with a public link
2. Add, update or delete some file from that link
3. An e-mail notification will arrive in 1 hour even if the batch time is set differently

Expected behavior

The email should arrive 24 Huors later

Nextcloud Server version

30

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.1

Web server

Apache (supported)

Database engine version

MySQL

Is this bug present after an update or on a fresh install?

Upgraded to a MAJOR version (ex. 31 to 32)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

List of activated Apps

Enabled:
  - activity: 3.0.0
  - admin_audit: 1.20.0
  - announcementcenter: 7.1.0
  - app_api: 4.0.6
  - bruteforcesettings: 3.0.0
  - calendar: 5.2.0
  - checksum: 1.2.6
  - cloud_federation_api: 1.13.0
  - comments: 1.20.1
  - contacts: 7.0.4
  - contactsinteraction: 1.11.0
  - dav: 1.31.1
  - deck: 1.14.4
  - federatedfilesharing: 1.20.0
  - federation: 1.20.0
  - files: 2.2.0
  - files_downloadlimit: 3.0.0
  - files_pdfviewer: 3.0.0
  - files_reminders: 1.3.0
  - files_retention: 1.19.0
  - files_sharing: 1.22.0
  - files_trashbin: 1.20.1
  - files_versions: 1.23.0
  - firstrunwizard: 3.0.0
  - impersonate: 1.17.1
  - logreader: 3.0.0
  - lookup_server_connector: 1.18.0
  - metadata: 0.22.0
  - nextcloud_announcements: 2.0.0
  - notifications: 3.0.0
  - notify_push: 1.0.0
  - oauth2: 1.18.1
  - password_policy: 2.0.0
  - photos: 3.0.2
  - piwik: 0.13.0
  - privacy: 2.0.0
  - provisioning_api: 1.20.0
  - recommendations: 3.0.0
  - related_resources: 1.5.0
  - serverinfo: 2.0.0
  - settings: 1.13.0
  - sharebymail: 1.20.0
  - spreed: 20.1.5
  - support: 2.0.0
  - survey_client: 2.0.0
  - suspicious_login: 8.0.0
  - systemtags: 1.20.0
  - tasks: 0.16.1
  - text: 4.1.0
  - theming: 2.6.0
  - twofactor_backupcodes: 1.19.0
  - twofactor_totp: 12.0.0-dev
  - updatenotification: 1.20.0
  - user_status: 1.10.0
  - viewer: 3.0.0
  - weather_status: 1.10.0
  - webhook_listeners: 1.1.0-dev
  - workflow_script: 1.15.0
  - workflowengine: 2.12.0
Disabled:
  - circles: 30.0.0 (installed 0.18.3)
  - dashboard: 7.10.0 (installed 7.2.0)
  - encryption: 2.18.0
  - files_external: 1.22.0 (installed 1.9.0)
  - files_readmemd: 3.0.2 (installed 3.0.2)
  - twofactor_nextcloud_notification: 4.0.0
  - user_ldap: 1.21.0

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

Additional info

No response

Start by reproducing the public_links_upload activity notification with daily batching, then trace how it is handled compared with other amq types. The issue is done when these notifications respect the configured batchtime and the regression is covered by an appropriate test.