fix(policy): load the authorization snapshot under the configured kind

FIX-MTR-22 (product fix landed; acceptance evidence still open, not pushed).

`load_latest_authz_json` parsed main's root tree with `Tree::from_mega_model`,
which derives every entry id from the thread-local HashKind. On a SHA-256
monorepo that either panics or resolves the wrong blob id, so the authorization
snapshot could never load.

It now parses through `tree_from_mega_model_with_kind` with
`monorepo.object_hash_kind()`, and propagates a parse failure as an error
instead of unwrapping. The published-version CAS, the dirty/monotonic snapshot
policy and the Cedar rules are untouched.

The whole existing notify module still passes (8/8). The multi-algorithm
read matrix, the pre-fix RED replay and the audit script for this card are not
yet produced, so no gate is claimed.

Signed-off-by: Eli Ma <eli@patch.sh>

Author: genedna

docs/plan/plan-20261015.md

@@ -5508,7 +5508,9 @@ FIX14和FIX-OX-25均涉及 `src/jupiter/tests.rs`；现行 `DEP-TR-WINDOW` 已
 
 **Task type:** `implementation`
 
-**Lifecycle / Acceptance:** `pending` / 空
+**Lifecycle / Acceptance:** `in-progress` / 空（产品修复已落地，验收证据未齐）
+
+**2026-10-31 产品修复已落地（验收未齐）：** `load_latest_authz_json` 原先以 `Tree::from_mega_model(tree)` 解析根树，该转换器按线程本地 `HashKind` 推导每个 entry 的 id，故在 SHA-256 monorepo 上会 panic 或取到错误 id。现改为 `tree_from_mega_model_with_kind(tree, storage.config().monorepo.object_hash_kind()?)`，解析失败以 `Result` 传播（对应 AC-2），不新增生产 `unwrap`、不改版本 CAS、dirty/monotonic 快照策略与 Cedar 规则。既有通知模块整模块 `cargo test -p mega2 --lib contract::policy::notify::` 实际 **8 passed / 0 failed**（VER-3 通过，AC-3/AC-4/AC-5 的既有语义未回归）。**仍未取得：** AC-1/AC-2/AC-6 需一个以三种算法分别建库、播种 `main@/` 根树与 `/.mega_cedar.json` blob 的 DB 级 fixture，本机尚未建立；VER-1 的前驱树 RED 回放、VER-2 的 `native_authz_hash_` 矩阵、VER-4 的仓外 `audit.py` 均未执行，故 A/C/ER05/D 零 claim，版本未 bump、未提交推送。
 
 **Description:** load_latest_authz_json以storage.config的算法解析根树，复用FIX15 fallible tree helper。独立修复authz通知读取，保留版本CAS、dirty/monotonic快照策略；不扩大权限或修改Cedar规则。 自FIX-MTR-17拆出，独立可发布/恢复，不以拆卡降低原矩阵。
 

src/contract/policy/notify.rs

@@ -29,9 +29,8 @@ use sea_orm::{ConnectionTrait, DbBackend, Statement, Value};
 use crate::{
     common::errors::MegaError,
     contract::policy::{enforcement::Enforcement, entitystore::MEGA_CEDAR_PATH},
-    jupiter::{
-        storage::{Storage, base_storage::StorageConnector, push_queue_storage::PushQueueStorage},
-        utils::converter::FromMegaModel,
+    jupiter::storage::{
+        Storage, base_storage::StorageConnector, push_queue_storage::PushQueueStorage,
     },
 };
 
@@ -409,7 +408,14 @@ async fn load_latest_authz_json(storage: &Storage) -> Result<Option<String>, Meg
     else {
         return Ok(None);
     };
-    let Some(blob_id) = authz_blob_id(&Tree::from_mega_model(tree)) else {
+    // Parse the root tree under the repository's configured object algorithm.
+    // `Tree::from_mega_model` derives every entry id from the thread-local
+    // HashKind, so on a SHA-256 monorepo it either panics or yields wrong ids.
+    let tree = crate::jupiter::utils::converter::tree_from_mega_model_with_kind(
+        tree,
+        storage.config().monorepo.object_hash_kind()?,
+    )?;
+    let Some(blob_id) = authz_blob_id(&tree) else {
         return Ok(None);
     };
     let content = match storage.git_service.get_object_as_bytes(&blob_id).await {