refactor: update README and project structure for native integration and OHOS support

- Enhanced README to clarify native integration methods for Android/iOS and OHOS.
- Updated project structure documentation to reflect changes in native capabilities and dependencies.
- Revised native integration documentation to specify transport methods for Android/iOS and OHOS.
- Documented the current implementation strategy for OHOS, emphasizing the use of MethodChannel for ArkTS.
- Adjusted SDK versioning notes to clarify the separation between Android/iOS and OHOS SDKs.

flutter-app/01-project-structure.md

@@ -30,7 +30,7 @@ conti-app/
     feature_analytics/        # 经营分析：对账单、核销收入、返利、报表
     feature_profile/          # 个人中心：地址、热线、客服
     feature_scan/             # 扫码业务入口（VIN/车牌/二维码/条码 → 分发到对应业务）
-    native_scan/              # 原生插件包：扫码 + VIN 识别（车牌走云端 OCR，不在这里）
+    native_scan/              # 原生能力 Dart facade；Android/iOS 是插件，OHOS 实现在 App entry
     native_media/             # 相机、相册、文件选择/上传
     native_device/            # 拨号、设备信息、权限申请
     native_crash/             # Bugly 崩溃上报的原生桥（见 13-observability-analytics.md）
@@ -43,7 +43,7 @@ conti-app/
 - `app` 可以依赖所有 `core_*` 和 `feature_*`。
 - `feature_*` **只能**依赖 `core_*` 和 `native_*`，**不能**相互依赖（`feature_purchase` 的 `pubspec.yaml` 里不允许出现 `feature_inventory` 的 path dependency）。
 - `core_*` 可以依赖 `native_*`（`core_webview` 的 JSBridge 需要调起扫码/相机/上传）。
-- `native_*` 只依赖 Flutter SDK 和 [Pigeon](https://pub.dev/packages/pigeon) 生成的代码，不依赖任何 `core_*` / `feature_*`——保证原生插件包可以脱离业务单独编译、单独测试（详见 [07-native-integration.md](./07-native-integration.md)）。
+- `native_*` 只依赖 Flutter SDK 与自身的跨平台 transport，不依赖任何 `core_*` / `feature_*`。Android/iOS transport 使用 [Pigeon](https://pub.dev/packages/pigeon) 生成代码；OHOS transport 可在 facade 内使用 `MethodChannel`，其 ArkTS 落在 App 宿主 `ohos/entry`，仍不得泄漏给业务层（详见 [07-native-integration.md](./07-native-integration.md)）。
 
 `core_*` 之间原则上不互相依赖，允许的例外只有下面三条，多一条都要走评审：
 
@@ -75,16 +75,19 @@ conti-app/
 
 - `core_xxx`：基础设施层，不含具体业务逻辑。
 - `feature_xxx`：对应一个业务域（多数是原来的某个小程序，也有全新的，如首页工作台）。
-- `native_xxx`：原生能力插件包，首版含 `android/`、`ios/` 两套原生实现目录（OHOS 不在首版范围，见 [07-native-integration.md](./07-native-integration.md)）。
+- `native_xxx`：业务侧唯一可依赖的原生能力 facade。Android/iOS 原生实现位于插件包；`harmony` 分支首期 OHOS ArkTS 实现位于 App 宿主的 `ohos/entry`，见 [07-native-integration.md](./07-native-integration.md)。
 
 ## SDK 版本基线
 
 | 项 | 版本 | 说明 |
 |---|---|---|
 | Flutter | **3.44.9** | 用 [FVM](https://fvm.app/) 锁定，仓库根目录提交 `.fvmrc` |
-| Dart | 随 Flutter 3.44.9 附带（3.12.x） | 具体号以 `flutter --version` 实测为准；`environment: sdk: ^3.12.0` 对整个 3.12.x 都成立 |
+| Dart | 随 Flutter 3.44.9 附带（3.12.x） | Android/iOS 基线具体号以 `flutter --version` 实测为准；包的下限使用 `environment: sdk: ^3.11.0`，以兼容已验证的 OHOS Dart 3.11.5 |
+| Flutter_OH（仅 `harmony`） | **3.41.10-ohos-1.0.0 / Dart 3.11.5** | 仅用于 OHOS 构建；由 `enable-ohos.ps1` 临时注入当前 PowerShell PATH，不能替换 Android/iOS 的 FVM SDK |
 
-**为什么不跟最新 stable（3.47.0 / Dart 3.13.0，2026-08-12 发布）**：鸿蒙（OpenHarmony）的 Flutter 分支适配落后于官方 stable 一段时间，虽然 OHOS 不在首版范围（见 [07-native-integration.md](./07-native-integration.md) 的「OHOS 后续演进」），但 SDK 基线要为后续接 OHOS 留出兼容窗口，所以刻意停在 3.44.9 而不是追最新。这条约束在决定升级 Flutter 版本时必须重新评估，不要因为"新版本有新特性"就单方面升。
+**OHOS SDK 边界**：OpenHarmony 的 Flutter 分支与官方 stable 不同步。Android/iOS 仍以 FVM 锁定的 Flutter 3.44.9 为基线；`harmony` 分支已用 Flutter_OH 3.41.10-ohos-1.0.0 / Dart 3.11.5 完成 HAP 编译验证。两套 SDK 不可混用，任一侧升级都必须重新验证依赖解析、生成代码和对应平台构建（见 [07-native-integration.md](./07-native-integration.md)）。
+
+**未来收敛条件**：当 Flutter_OH 发布并验证可用的 Flutter **3.44.x / Dart 3.12.x** 对齐版本时，可评审将 `harmony` 与 Android/iOS 收敛到同一 SDK 基线。版本号相同不是自动放行条件；必须重新完成依赖解析、Riverpod/Pigeon 生成物核验、HAP 构建及真机原生能力验证后才能切换。
 
 **为什么必须用 FVM 锁**：monorepo 里各人本地 Flutter 版本不一致，会导致同一份代码有人 `flutter analyze` 过、有人不过，生成代码（`build_runner` 产物）也可能不一致——这类问题排查成本远高于装一次 FVM。CI 也用 `.fvmrc` 里的版本，保证本地和流水线一致。
 
@@ -264,4 +267,3 @@ dart pub global activate melos
 - [Pigeon | Dart package](https://pub.dev/packages/pigeon)
 - [Drift | Dart package](https://pub.dev/packages/drift)
 - [Lerna（JS 生态对标工具）](https://lerna.js.org/)
-