normalize predefined push rule actions to match spec defaults

[Reaster0]

Fix silent push notifications when homeserver provides non-spec default push rules

Problem

Some homeservers (notably Continuwuity) provide predefined push rules with actions that differ from the Matrix spec defaults. For example, the spec defines that .m.rule.room_one_to_one
should include a {"set_tweak": "sound", "value": "default"} action, but these servers omit it.

This causes the SDK's NotificationItem::is_noisy to always evaluate to false, which downstream clients (Element X iOS, Element X Android) rely on to decide whether to play a notification
sound. The result is that all notifications are completely silent — no sound, no vibration — for users on affected homeservers.

Other clients like FluffyChat and Element Web are unaffected because they either handle sound independently of push rule evaluation or run in-process where the distinction doesn't matter.

Context

• Element X iOS issue: Won't get sound / vibration for notification on iOS element-hq/element-x-ios#5132
• Continuwuity upstream discussion: https://forgejo.ellis.link/continuwuation/continuwuity/issues/1533
• NSE check that gates sound: NotificationContentBuilder.swift:51-52
• Element X iOS maintainer confirmed the fix belongs in this SDK

Solution

Introduce normalize_predefined_push_rule_actions(), which replaces the actions of predefined push rules (those with default: true) with the spec-defined actions from
Ruleset::server_default(), while preserving the enabled state from the server. This is applied at both push rule loading points:

1. BaseClient::get_push_rules() — used during sync processing (sliding sync & v2 sync)
2. Account::push_rules() — used by the notification client's /context query path

Rules that are not server defaults (default: false), such as user-created custom rules, are left completely untouched.

Trade-offs

This approach enforces the spec-defined actions for predefined rules, which means if a user explicitly modified the actions of a predefined rule (e.g., removed the sound tweak from
.m.rule.room_one_to_one via the push rules API), that customization would be overridden. However:

• The enabled/disabled state is always preserved — disabling a rule still works

• User-created custom rules are never touched

• Modifying predefined rule actions is uncommon; disabling rules is the standard UX

• The alternative (permanent silent notifications for all users on non-compliant servers) is a significantly worse outcome

• The spec defines what these actions should be — clients enforcing them is defensible

  Testing

• 3 new unit tests covering:

  • Restoring missing sound tweaks (the core bug)
  • Preserving enabled state from server
  • Leaving non-default (user-created) rules untouched

• All 20 existing notification client tests continue to pass

[codecov]

Codecov Report

❌ Patch coverage is 97.46835% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.89%. Comparing base (abc6b4a) to head (3ad582c).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
crates/matrix-sdk-base/src/client.rs	97.29%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6296      +/-   ##
==========================================
+ Coverage   89.87%   89.89%   +0.01%     
==========================================
  Files         374      374              
  Lines      102275   102347      +72     
  Branches   102275   102347      +72     
==========================================
+ Hits        91923    92003      +80     
+ Misses       6787     6781       -6     
+ Partials     3565     3563       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[codspeed-hq]

Merging this PR will not alter performance

✅ 50 untouched benchmarks

---

_{Comparing Reaster0:normalize-predefined-push-rule-actions-to-match-spec-defaults (3ad582c) with main (abc6b4a)}

[BillCarsonFr]

@Reaster0

Maybe the way to go would be to update the notification settings screen on the clients so that they can properly make notification noisy or not?

A bit like the advanced notification panel on web

Like that you could see what is silent and what is noisy and then change it?

[Reaster0]

well yeah that would be good, that would be a good idea, but defaulting to silent by default in certains case is not really easy for non power users no?
the process to:
open the app -> notice the notifs are silent -> debug the notifs settings -> enable the noisy notifs

is not really straight forward for non power user no? the opposite would be more user friendly i think (having to fidget the settings in case you want to "mute" some kind of notif) at least that's how it is on most chat apps,

would you think it's better to default to noisy only when the settings panel exist?

[BillCarsonFr]

to silent by default in certains case is not really easy for non power users no?

That is a good point @Reaster0 , the noisy/silent setting is a complex setting (power user).
That's probably why it is not even visible in the EX settings (?).
I will raise with product to see how to best progress on that.

Meanwhile let's wait for kovapatrik conclusions here as he is saying he will dive deeper.
Then we'll be able to decide what is spec complient or not, what needs to be updated / clarfied, etc...

[BillCarsonFr]

@Reaster0 I created an issue here for both EXI and EXA to get product feedack and track comments
element-hq/element-meta#3186