fix(user_status): one heartbeat per interval, and refresh before invalidation

[solracsf]

Summary

Two fixes that need to land together, one in the browser and one on the server.

The heartbeat fires on every mouse movement

The away countdown was cancelled with clearTimeout(this.setAwayTimeout), which passes the callback instead of the id setTimeout returned. Nothing was ever cancelled and the id was thrown away, so every burst of mouse movement left another two minute timer running. Each one that expired marked an active user as away, and the next movement flipped them back and sent a heartbeat. An ordinary session ends up sending around 593 heartbeats an hour instead of the 13 the code intends, and holding a timer for each one.

The scheduling moves into src/services/heartbeatScheduler.ts so it can be tested without mounting the component. That also fixes the teardown: the listener was added as mousemove with capture and removed as mouseMove without it, so it was never actually removed and every unmounted component leaked one.

A live status is invalidated before it gets refreshed

UserLiveStatusListener only refreshed status_timestamp once it was already older than INVALIDATE_STATUS_THRESHOLD, which is the same 15 minutes at which ClearOldStatusesBackgroundJob sweeps a status to offline. The job runs every minute and the client heartbeats every five, so an active user can show up as offline for up to five minutes until their next heartbeat lands.

The refresh now happens at a new REFRESH_STATUS_THRESHOLD of 7 minutes, which caps the age of a live status at 12 minutes (the refresh threshold plus one heartbeat interval), well under the 15 at which it gets swept.

Why they go together

The first fix is what makes the second bug visible. Before it, an active user flapped between away and online every couple of seconds, and every flip hits the listener's priority branch and refreshes the timestamp. That is what was hiding the stale refresh.

Going from 593 heartbeats an hour down to 13 would open the offline window on its own, so these two should not be split.

Trade-offs

An active user's oc_user_status row is now written roughly every 10 minutes instead of every 20, so twice the writes on that table, against 45x fewer heartbeat requests.

REFRESH_STATUS_THRESHOLD assumes no client heartbeats slower than 8 minutes. Web, desktop, mobile and Talk all call the same OCS endpoint, so if any of them ever uses a slower interval the constant needs a second look.

Testing

heartbeatScheduler.spec.ts reports 593 calls against the old inline logic where it expects 13, and its teardown test catches the leaked listener. UserLiveStatusListenerIntegrationTest steps time at the cleanup job's one minute cadence and asserts after every sweep, and it fails at minute 15 without the server fix. Two rows were added to the UserLiveStatusListenerTest provider for the new threshold. The full apps/user_status suite (205 tests) is green on MariaDB 11.8 and PostgreSQL 16.

Checklist

• Tests (unit, integration) are included
• Screenshots before/after for front-end changes (no visual change)
• Documentation has been updated or is not required
• Backports requested where applicable
• Labels added where applicable
• Milestone added for target branch/version

AI (if applicable)

• The content of this PR was partly or fully generated using AI