Introduce ServerUserAvatarRepository

[TimoPtr]

Summary

This PR introduce a new manager ServerUserAvatarRepository that is not yet use in this PR. This repository contains the logic to retrieve the Avatar image from core for a given server. We ensure to also cache the image whenever we can to avoid downloading it multiple times.

Checklist

• New or updated tests have been added to cover the changes following the testing guidelines.
• The code follows the project's code style and best_practices.
• The changes have been thoroughly tested, and edge cases have been considered.
• Changes are backward compatible whenever feasible. Any breaking changes are documented in the changelog for users and/or in the code for developers depending on the relevance.

Any other notes

If the server is not available it doesn't return anything because we need the list of entities to get the cache key. We cannot enumerate the disk cache because the key is transformed to a sha256 so looking at the filesystem attribute of the fileLoader won't help us to find the cache without knowing the full cache key.

This doesn't leave in :common because it rely on coil.

[Copilot]

Pull request overview

This PR introduces a new ServerUserAvatarManager utility intended to load the current user’s avatar for a given Home Assistant server by locating the linked person entity, downloading the entity_picture via Coil with authentication, and leveraging Coil caching to avoid repeat downloads.

Changes:

• Added ServerUserAvatarManager for avatar lookup/download + cache fallback behavior
• Introduced PERSON_DOMAIN constant and replaced hardcoded "person" usage in Entity utilities
• Added Entity.isPersonOf(userId) helper and unit tests covering the manager’s behavior

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
common/src/main/kotlin/io/homeassistant/companion/android/common/data/integration/IntegrationDomains.kt	Adds PERSON_DOMAIN constant for consistent domain usage
common/src/main/kotlin/io/homeassistant/companion/android/common/data/integration/Entity.kt	Switches to PERSON_DOMAIN and adds isPersonOf(userId) helper
app/src/main/kotlin/io/homeassistant/companion/android/util/ServerUserAvatarManager.kt	New manager to resolve/download user avatar and read from Coil caches
app/src/test/kotlin/io/homeassistant/companion/android/util/ServerUserAvatarManagerTest.kt	Adds unit coverage for avatar resolution, caching keys, and request properties

[jpelgrom]

I think this raises some architecture questions, sorry

• This looks most like the pair of *UseCase classes we have: very specific repository usage with some light handling on top of it to make it easy to use and avoid repeating yourself. Isn't that a manager? You even called it manager in the description.
• If we go with repository, I don't think we should put repositories in a util package... Probably its own or grouped together with the most closely related repository package.

[TimoPtr]

I think this raises some architecture questions, sorry

* This looks most like the pair of `*UseCase` classes we have: very specific repository usage with some light handling on top of it to make it easy to use and avoid repeating yourself. Isn't that a manager? You even called it manager in the description.

* If we go with repository, I don't think we should put repositories in a util package... Probably its own or grouped together with the most closely related repository package.

I renamed it from Manager to Repository because in the next PR that uses it I've introduced a ServerChooserItemsManager that use the Repository to build the items. If we agree to introduce Use Cases I have this proposal we rename the current repository to Manager and the ServerChooserItemsManager to ServerChooserItemsUseCase, Use Case becoming something very specific that could be reused into multiple places implementing one specific logic on top of potentially a Manager? Otherwise if we stick to our current doc ServerChooserItemsHandler.

[jpelgrom]

Naming aside, the code here looks good.

If we agree to introduce Use Cases I have this proposal we rename the current repository to Manager and the ServerChooserItemsManager to ServerChooserItemsUseCase, Use Case becoming something very specific that could be reused into multiple places implementing one specific logic on top of potentially a Manager? Otherwise if we stick to our current doc ServerChooserItemsHandler.

I don't follow this logic. The code in this PR looks like a use case to me; the ServerChooserItemsManager as well or like a util function tbh, there's only 2 lines of actual code in it.