feat(api): auto-activate streak freeze on inactive day (#108)

[thomasluizon]

Refs thomasluizon/orbit-ui-mobile#108

What

A dedicated StreakFreezeAutoActivationService BackgroundService that auto-activates a streak freeze for a Pro user who held an active streak but logged nothing on their fully-elapsed local "yesterday". The paired UI PR makes the Today-header streak badge tappable.

How

• Mirrors SlipAlertSchedulerService / HabitDueDateAdvancementService: configurable poll interval (BackgroundServices:StreakFreezeIntervalMinutes, default 60), conservative UTC AddDays(-1) pre-filter, then authoritative per-user TimeZoneHelper local-yesterday guard; single SaveChangesAsync per tick.
• Pro-only (user.HasProAccess, matching ActivateStreakFreezeCommand). Spends one freeze per missed day, bounded by MaxStreakFreezesAccumulated (inventory via User.ConsumeStreakFreeze()) and MaxStreakFreezesPerMonth (calendar-month window).
• Presence-based invariant: inserting a StreakFreeze row for the missed date is sufficient — UserStreakService.ComputeCurrentStreak treats any freeze-covered date as covered, so the next on-read RecalculateAsync preserves CurrentStreak without any direct mutation here.
• Idempotency: new SentStreakFreezeAlert guard entity (unique (UserId, FrozenDate)) + the existing StreakFreeze unique (UserId, UsedOnDate) index, both batch-loaded and re-checked before spending → no double-spend, no duplicate notification across polls.
• Notify: in-app Notification.Create + push (IPushNotificationService.SendToUserAsync), deep-linking to /streak. Copy is server-generated and localized via LocaleHelper.IsPortuguese, mirroring GoalDeadlineNotificationService (no AI dependency).
• EF migration AddSentStreakFreezeAlert (table + unique index + cascade FK). AccountResetRepository purges the new guard table. Registered in ServiceCollectionExtensions and BackgroundServiceHealthCheck.
• No late-log refund in this issue (documented follow-up in the plan).
• Not folded into HabitDueDateAdvancementService — kept dedicated so streak logic never re-hides overdue habits.

Rebase note

The ServiceCollectionExtensions.cs hosted-services region (~345) differs from the regions touched by #78 (Stripe ~308-326) and #79 (AI-tools ~153-198) — this is a trivial rebase at merge.

Tests / validation

• dotnet build clean (0 errors).
• New unit tests cover the eligibility predicate (include/exclude cases), local-yesterday computation, the 60-min interval default, localized notification copy, and the guard entity.
• dotnet test unit projects green: Infrastructure.Tests 931, Domain.Tests 344, Application.Tests 1679. The freeze-preserves-streak invariant is already covered by existing UserStreakServiceTests (not duplicated).
• IntegrationTests not run in CI sandbox here (host bootstrap needs a 32-byte Jwt:SecretKey + DB) — flagged as manual.

Paired UI PR

thomasluizon/orbit-ui-mobile#129

[claude]

One correctness bug: LoadRecentCompletionsAsync omits !h.IsDeleted from the habit filter, but UserStreakService.LoadStreakDataAsync (the source of truth for streak computation) requires both !h.IsDeleted && !h.IsBadHabit. A user who logged a now-deleted habit on the missed date will be treated as 'active' by this service, preventing the auto-freeze — yet UserStreakService won't count that log, so the streak breaks anyway. One-character fix: add && !h.IsDeleted to the WHERE predicate on line 108. Everything else looks solid: idempotency design, monthly cap, Pro guard, migration, health-check registration, and unit test coverage are all correct.

[claude]

The second commit removed the manual ActivateStreakFreezeCommand cleanly, but the one correctness bug I flagged in my prior review was not addressed: LoadRecentCompletionsAsync still omits !h.IsDeleted from the habit WHERE predicate (line 108). One-character fix — see inline comment. Everything else is solid.

[claude]

The third commit cleanly resolves the correctness bug I flagged in both prior reviews: LoadRecentCompletionsAsync now filters !h.IsDeleted && !h.IsBadHabit on the habit predicate (line 108), matching the UserStreakService source of truth, and two DB-backed unit tests lock that contract against regression. The rest of the implementation holds up on re-read: idempotency is solid (double-guard via StreakFreeze unique index + SentStreakFreezeAlert), the monthly cap window is correct, Pro-only guard is enforced in memory after the conservative UTC pre-filter, SentStreakFreezeAlerts is purged in AccountResetRepository, the health check entry uses a 3× staleness threshold, and the migration/EF config is consistent with the other guard-entity pattern in the codebase. Good to merge.