Let the room list avatar be tapped to see it larger

[hayaksi1]

Content

Tapping a room's avatar opens it full screen everywhere else in the app — in the timeline top bar, in
the room details, and on a user's profile. In the room list it had no meaning of its own: the tap fell
through to the row and opened the room.

The room list avatar now opens the same media viewer, through a new AvatarPreview target on the home
flow, reusing MediaViewerEntryPoint.createParamsForAvatar exactly as the other three screens do.

It is only clickable when there is an avatar to show. A room with a generated letter avatar, and an
invitation whose avatar is being hidden, still open the room on a tap as before, so the row keeps its
whole tap target in the cases where a larger view would show nothing.

Motivation and context

Part of #6970

Tests

• RoomListViewTest.clicking on the avatar of a room that has one invokes the avatar callback
• RoomListViewTest.the avatar of a room that has none is not clickable
• Both were run against the unfixed code and both fail there.
• They cover the row's behaviour, not the media viewer itself, which is unchanged and already covered.

Screenshots / GIFs

The only golden that moved is features.home.impl_HomeViewA11y_en.png: the accessibility overlay
draws the avatar's new click action. Every ordinary snapshot is byte-identical, since nothing about
the row's layout or colours changed.

Tested devices

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

Checklist

• 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 changelog
• Pull request includes screenshots or videos if containing UI changes
• Pull request includes a sign off
• You've made a self review of your PR
• If you have modified the UI, check that the design is compliant with the design system
• I declare that I have used AI assistance for this contribution

[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.

[frebib]

As a person that is predominantly left-handed: I absolutely detest this "feature" in WhatsApp. I often click the avatar to open the room because that's where my finger happens to land on the left-hand side of the screen. If anything I'd argue this is right-hand-preferential and as such am not a fan.