refactor: remove CrashReporter and related logging components

- Removed CrashReporter interface and its implementation, SentryCrashReporter.
- Deleted log buffering functionality and associated LogBuffer class.
- Updated LoggerAppLogger to eliminate dependencies on removed components.
- Simplified logging structure to focus on AppLogger and sensitive data scrubbing.
- Adjusted AppEnv to remove Sentry-related configurations.
- Refactored tests to align with the new logging architecture.

docs/11-store-context-and-session.md

@@ -145,8 +145,7 @@ Future<void> switchStore(int targetStoreId) async {
   // ── 7. 记住这次选择，供下次冷启动预选 ────────────────
   await ref.read(prefsProvider).setInt('last_store_id', newStore.storeId);
 
-  // ── 8. 同步观测上下文（见 13）────────────────────────
-  ref.read(crashReporterProvider).setTag('storeId', '${newStore.storeId}');
+  // ── 8. 同步埋点上下文 ──────────────────────────────────
   ref.read(analyticsProvider).registerSuperProperties({'storeId': newStore.storeId});
   // 切店事件本身由后端从 /stores/{id}/switch 的接口日志出，客户端不重复上报，见 13
 }
@@ -158,7 +157,7 @@ Future<void> switchStore(int targetStoreId) async {
 | 3 在 5 之前 | H5 页面里可能有在途请求。先 `about:blank` 停掉，再换上下文，否则旧门店的 H5 请求会带着新门店的票据回来 |
 | 4 在 5 之前 | 缓存表带 `storeId`（见 06），但**清理和新上下文之间不能有窗口期**：如果先落新上下文，provider 立刻失效并重新请求，可能在清理完成前就把新数据写进去，然后被 `clearBusinessCache()` 一起删掉 |
 | 6 在 5 之后 | 清栈时目标页面（首页）要用新上下文渲染 |
-| 8 在 5 之后 | 观测上下文要和业务上下文保持一致；漏了这一步的表现是**切店后的崩溃和埋点还挂在旧门店名下**，按门店维度分析时数据是错的，而且错得很隐蔽 |
+| 8 在 5 之后 | 埋点上下文要和业务上下文保持一致；漏了这一步会让切店后的埋点还挂在旧门店名下，按门店维度分析时数据会悄悄出错 |
 
 **关于步骤 0（未完成写操作）**：切店时用户可能正在提交订单或上传图片。默认策略是**阻止切换并提示**，而不是静默取消——取消一个已经发出去的下单请求，客户端不知道服务端到底成没成。`pendingWriteProvider` 由发起写操作的 feature 自己注册/注销。
 
@@ -190,7 +189,6 @@ Future<void> logout({LogoutReason reason = LogoutReason.userInitiated}) async {
   ref.read(analyticsProvider)
     ..track(AnalyticsEvent.logout, {'reason': reason.name})   // 报完再 reset，顺序不能反
     ..reset();
-  ref.read(crashReporterProvider).setUser('');
 
   // 6. 兜底：清掉所有 provider 缓存
   ref.invalidate(...); // 或在 ProviderScope 层重建，见下文