fix(reminder): 地点提醒常驻守护在进程被杀后无法恢复投递

[LUPENGHAN]

Summary

• 真正的根因：expo-task-manager（及其依赖 unimodules-app-loader）默认从 Maven 拉官方预编译二进制，不读 node_modules 本地源码。这意味着此前打的所有补丁（下面这些）从未被真正编译进任何 APK，之前几轮"打了 patch 还是不行"的观测因此都不算数。在 package.json 加 expo.autolinking.buildFromSource 逼这两个模块走本地源码编译后，补丁才第一次真正生效。
• 打上上游 expo/expo#47958 的修复（patches/expo-task-manager+57.0.9.patch，patch-package 自动生效）
• ReminderGuardCoordinator 新增陈旧检测：不再拿原生注册 options（foreground/degraded）当"还在投递"的证据，改用"本进程是否自己成功建过注册 + 最近是否收到过心跳"判断；检测到继承自上一个（已死）进程的注册时主动重建（含真正的 TaskManager.unregisterTaskAsync()）
• 保留诊断日志（[guard] state=... stale=... wantInterval=... / [guard] registered interval=... / [guard] refreshed interval=... withService=...），后续复测和排查用
• 顺带把地点提醒触发半径从 400m 调到 200m

背景

详见 #413。地点提醒依赖的常驻定位守护，在 App 进程被系统杀掉后，原生位置订阅仍在正常投递（adb dumpsys location 证实），但 expo-task-manager 的 defineTask 回调收不到，此前只有卸载重装能恢复。

已通过真机端到端验证 ✅

补上 buildFromSource 配置、确认 patch 真正编译进 APK 之后：强杀重开 App，走出围栏再走回来，日志出现：

[reminder] TRIGGERED, delivering 193b46bc72014283aac0fced5b2c6ab5 拿快递

原生响铃/通知正常展示。多轮心跳（[guard] dispatching sample to the live listener）持续稳定，未再出现"冷启动余波后彻底沉默"的旧现象。

Test plan

• npx jest（830+ 测试全过）
• npx tsc --noEmit
• npx eslint（无新增问题）
• 真机：强杀重开后，走出围栏再走回来，[reminder] TRIGGERED 正常触发且原生弹窗/通知正常展示
• 真机：确认 TimeflowDiag 诊断字符串真的编进了安装的 APK（unzip + grep dex 直接验证），排除"改了但没编译进去"的可能

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Flag	Coverage Δ
backend	96.57% <ø> (ø)
frontend	91.10% <100.00%> (+0.04%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...s/reminder/application/ReminderGuardCoordinator.ts	100.00% <100.00%> (ø)
frontend/src/features/reminder/domain/geofence.ts	82.97% <100.00%> (ø)
...d/src/infrastructure/location/reminderGuardTask.ts	64.70% <ø> (ø)

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[fennoai]

审阅了构建配置、TaskManager backport、守护注册协调器、headless 刷新路径及新增单测。当前实现能在冷启动时重建继承注册，但运行中的静默失活和清理失败路径仍可能让地点/时间提醒永久停摆，建议先修复以下两处。

Additional findings

• frontend/src/features/reminder/application/ReminderGuardCoordinator.ts:?: [P1] Do not restart after failed task unregistration: 如果 unregisterTaskAsync() 抛错，这里仍继续执行 startLocationUpdatesAsync() 并把 ownsRegistration 设为 true。但本次改动的根因和注释都说明持久化的 TaskManager 注册必须被真正移除；清理失败时继续复用同名注册可能再次命中同一个失活的原生记录，随后协调器又会把它当成健康注册而提前返回，导致恢复失败。请在注销失败时中止本次重建并保留可重试状态（或确认注销成功后再启动）。

[LUPENGHAN]

两条 P1 都确认是真问题，已在 ff2d5bc 修复：

1. 注销失败后仍继续重建：unregisterTaskAsync() 抛错时改为直接 return，中止本次重建，不再往下调 startLocationUpdatesAsync()——避免持久化记录没清干净、又绑上同一条失活记录，还把 ownsRegistration/lastProgressAt 乐观地标成"刚建好"，把失活状态盖住。
2. 无独立重试（内联评论已回复）：加了 watchdog 定时器。

CI 那次 Frontend 失败是 prettier --check 没过（新加的 package.json 字段格式不对），同一个 commit 里一起修了。