All checks were successful
CI / Check spelling (pull_request) Successful in 1m26s
CI / Check coding style (pull_request) Successful in 1m37s
CI / Linux (debian) (pull_request) Successful in 9m54s
CI / Linux (ubuntu) (pull_request) Successful in 10m11s
CI / Linux (fedora) (pull_request) Successful in 14m56s
CI / Linux (arch) (pull_request) Successful in 16m38s
CI / Check spelling (push) Successful in 15s
CI / Check coding style (push) Successful in 26s
CI / Linux (debian) (push) Successful in 9m49s
CI / Linux (ubuntu) (push) Successful in 10m1s
CI / Linux (fedora) (push) Successful in 12m59s
CI / Linux (arch) (push) Successful in 13m51s
Previously, features like `XMPP_FEATURE_OMEMO_DEVICELIST_NOTIFY` were added in separate init methods (e.g., `omemo_devicelist_subscribe`) via `caps_add_feature`, triggering `cl_ev_presence_send` and sending multiple "online" XMPP presence stanzas. This caused other clients to see users as appearing "online" multiple times. This change adds `STANZA_NS_MOOD_NOTIFY` and `XMPP_FEATURE_OMEMO_DEVICELIST_NOTIFY` in `caps_init`, ensuring they are in `prof_features` early. This allows `caps_add_feature` to exit early when called for these features, avoiding redundant presence updates.