Let the user turn off conversation notifications

[hayaksi1]

Content

Every room notification carries a shortcut id, which is what makes it an Android conversation, and a
conversation is exempt from Do Not Disturb whenever the system policy allows conversations from
anyone. The channel does not ask for a bypass — the exemption comes purely from conversation status —
and there is no way to opt out from inside the app.

Notification settings gain a switch, on by default so nothing changes for anyone who wants today's
behaviour. Turning it off stops setShortcutId being called on new notifications, stops a shortcut
being published when a message is sent, and clears the shortcuts already published, since those are
what make the notifications already on screen conversations.

Motivation and context

Closes #7471. The reporter measured it with adb: with DND active, the records carrying a shortcut
were logged not_intercepted … new:conversationAnyone while the shortcut-less group summary was
intercepted. Their device's ROM exposes no conversation settings, so the system-side control the
feature relies on does not exist for them.

The default stays on deliberately: #1547 asked for conversation notifications and #7056 reports their
loss as a regression, so this is an escape hatch rather than a change of behaviour.

The new strings are in temporary.xml per AGENTS.md.

Tests

libraries/push/impl/.../factories/DefaultNotificationCreatorTest.kt asserts the notification carries
a shortcut id with the setting on and none with it off.
DefaultNotificationConversationServiceTest covers the two shortcut paths: none is published while
the setting is off, and the existing ones are cleared when it is turned off.

All three fail on develop, which always sets the shortcut.

Run with ./gradlew :libraries:push:impl:testDebugUnitTest.

Tested devices

• Physical
• Emulator
• OS version(s):

Checklist

• I am aware of the etiquette.
• This PR was made with the help of AI:
  • Yes. In this case, please request a review by Copilot.
  • No.
• Changes have been tested on an Android device or Android emulator with API 24
• UI change has been tested on both light and dark themes
• Accessibility has been taken into account. See https://github.com/element-hq/element-x-android/blob/develop/CONTRIBUTING.md#accessibility
• Pull request is based on the develop branch
• Pull request title will be used in the release note, it clearly defines what will change for the user
• Pull request includes screenshots or videos if containing UI changes
• You've made a self review of your PR

[github-actions]

Thank you for your contribution! Here are a few things to check in the PR to ensure it's reviewed as quickly as possible:

• If your pull request adds a feature or modifies the UI, this should have an equivalent pull request in the Element X iOS repo unless it only affects an Android-only behaviour or is behind a disabled feature flag, since we need parity in both clients to consider a feature done. It will also need to be approved by our product and design teams before being merged, so it's usually a good idea to discuss the changes in a Github issue first and then start working on them once the approach has been validated.
• Your branch should be based on origin/develop, at least when it was created.
• The title of the PR will be used for release notes, so it needs to describe the change visible to the user.
• The test pass locally running ./gradlew test.
• The code quality check suite pass locally running ./gradlew runQualityChecks.
• If you modified anything related to the UI, including previews, you'll have to run the Record screenshots GH action in your forked repo: that will generate compatible new screenshots. However, given Github Actions limitations, it will prevent the CI from running temporarily, until you upload a new commit after that one. To do so, just pull the latest changes and push an empty commit.