已完成修正（小弟）

白話說明

原本「雲端空間整合」這頁的連線 / 中斷 / 重建等操作，程式判斷的是帳號層的 root 旗標（is_super_admin），全系統只有 root admin 這一個帳號是 true。所以 blsadmin 這種「租戶管理員」按下去必然被擋，而且跳出來的錯誤訊息寫「需要 tenant admin 權限」——訊息講的跟實際在判的是兩回事，才會看起來莫名其妙。

這次把判斷改成跟 SMTP、LDAP、Log 轉發同一套「能力點」機制：不再問「你是不是 root」，改問「你這個角色有沒有被授予這項能力」。租戶管理員本來就有這些能力，改完就通了。

改了哪些端點（BE）

守門一律掛在 route 層（順序：登入 → 授權照 → 能力點）：

| 端點 | 需要的能力點 |

|---|---|

| POST auth-url（連線 / 重新授權） | cloud_integration.create |

| DELETE（中斷連線） | cloud_integration.delete |

| GET sync-jobs（同步紀錄） | cloud_integration.read |

| POST sync-jobs/<uid>/retry（重試） | cloud_integration.update |

| POST tenant/rebuild-all（重建目錄） | cloud_integration.update |

| POST webhook/register | cloud_integration.update（原為 root-only） |

service 層那條 is_admin 參數鏈全部拆掉，守門集中在 route 層一處；disconnect 裡另外那條 _is_super_admin 旁路也一併移除（它跟傳進來的 is_admin 判的是同一件事，等於同一個判定寫了兩遍）。錯誤碼不再用那個會誤導人的 GRC_NOT_ADMIN，改標準能力點 403（GRC_403022）。

🔴 與卡片描述不同的地方（請決策者過目）

卡片第 ① 點要求建 migration 新增能力點，但實際查過 DB 後確認「不需要，而且不該建」：

• cloud_integration.{read,create,update,delete} 這四個能力點 2026-04-27 就已經存在（migration 2026-04-27-add-audit-and-cloud-integration-permissions.sql），is_platform=false，也早就綁好選單路由 cloud-integrations。
• DEV 實查：role 2/3/38/39/43/44/49 共七個角色全部都已持有這四個能力點，比 smtp-config 的持有面還廣（smtp-config.update 其實只有 role 2 有）。blsadmin 所屬的 role 3 四個全有。
• 新開的租戶：provisioning 的排除清單不含 cloud_integration，且 is_platform=false 不會被 platform guard 擋掉，所以新租戶的 System Manager 會自動拿到。