Evaluate stronger AccountType modeling

[johan456789]

Context

AccountType is currently a regular Kotlin class wrapping an integer id. Because it is not a data class and does not override equals, comparisons like account.type == AccountType.Local use object identity rather than value equality. PR #70 fixed the immediate read-state issue by comparing account.type.id instead.

Proposal to research

Investigate whether AccountType should be modeled more strongly, for example as an enum class, sealed type, value class, or another value-like representation.

Research needed

Further research is needed before changing this because the type is used across Room converters, persisted preferences, account creation, service selection, UI branching, and sync behavior. The work should verify migration/backward-compatibility implications and whether any existing code relies on the current wrapper-class behavior.

Acceptance criteria

• Document the tradeoffs of keeping the current id-wrapper approach versus moving to a stronger type.
• Audit all AccountType comparisons and conversions.
• Confirm compatibility with Room type converters and stored account type ids.
• If a refactor is recommended, propose a low-risk migration plan with tests.