Offer to shuffle the digits of the PIN keypad

[hayaksi1]

Content

The PIN keypad always draws 1 to 0 in the same nine positions, so anyone standing close enough to watch the movement of a finger can read the PIN back without seeing the screen at all. A new switch under Screen lock draws the digits in a random order instead, keeping the same grid so the pad still looks and behaves the way it did.

The order is drawn once per unlock screen rather than after every key, so a PIN can still be entered without hunting for each digit twice. The setting is off by default and lives next to the biometric unlock switch, in the same store.

Motivation and context

Relates to #6031.

Tests

• PinKeypadTest — a shuffled keypad still offers every digit exactly once, and clicking a digit still emits that digit rather than the one that used to sit in that position.
• The existing keypad and unlock tests are unchanged and still pass with shuffling off.

These do not assert that a shuffled pad differs from an unshuffled one, which is not deterministic; they assert that shuffling never loses, duplicates or mislabels a key.

Tested devices

• Physical
• Emulator
• OS version(s): API 36

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.

[bmarty]

Nice. We will need a product validation first.

Also, the current layout with the 0 at the bottom is quite a standard digit-keypad, but with a random number at this position, this could look weird...