Spike: Investigate locale-aware date formatting in TimeProvider

[MessiasLima]

Description

Background

TimeProvider is the central source for time formatting in the app. Its current implementation (DefaultTimeProvider) uses a hardcoded LocalDate.Format with MonthNames.ENGLISH_ABBREVIATED, producing dates like "22 Jul 2026" regardless of the user's app language. Foliary supports dozens of locales via Lingo.dev string resources, so the date format should align with the user's chosen application locale or system language.

Current Knowledge

• DefaultTimeProvider in foliary/src/commonMain/kotlin/dev/appoutlet/foliary/core/provider/time/TimeProvider.kt hardcodes a single date format using day(), monthName(MonthNames.ENGLISH_ABBREVIATED), and year().
• displayText(...) is used by CreateTaskViewModel to render the selected due date and by other UI components that map task data to view data.
• FoliaryTaskCardViewDataMapper currently relies only on timeProvider.now() for overdue calculations, but TimeProvider is injected and may be used for date formatting in future task-card designs.
• The project already maintains values-<locale>/strings.xml for many target locales via i18n.json (e.g., ar, de, fr, ja, pt-rBR, zh).
• There is no existing locale provider or expect/actual mechanism in the core module to expose the current application locale to shared code.
• kotlinx-datetime does not provide built-in locale-aware formatting, so a solution will likely require platform-specific APIs or an explicit locale abstraction.

Scope

In scope:

• Identify how to obtain the current application locale in a KMP commonMain context for Android, iOS, and Desktop.
• Compare options for locale-aware date formatting without introducing a new dependency unless required.
• Determine how TimeProvider should receive locale information (e.g., constructor parameter, separate locale provider, or platform-specific formatting implementation).
• Assess impact on existing callers and unit tests (currently asserting "22 Jul 2026").

Out of scope:

• Implementing the actual change.
• Adding new translation strings.
• UI/UX redesign of the date picker or task card.

Outcomes

• Document the recommended approach for retrieving the current application locale in commonMain across Android, iOS, and Desktop.
• List and compare at least two formatting options, including trade-offs around dependencies, testing, and RTL/locale edge cases.
• Propose an updated TimeProvider API design that keeps the change minimal and testable.
• Identify the implementation tickets needed after this spike (e.g., "Create locale provider", "Update TimeProvider to use locale", "Update date format tests").
• Produce a short decision record or comment in the spike issue with the chosen direction.