白話說：「Log 轉發設定」這一頁被系統誤判成「貴公司沒買這個模組」，所以角色權限矩陣把它整列標成「未授權」。實際上這頁跟「郵件伺服器」「LDAP」一樣屬於機房設定、不是賣的商品，本來就不該受授權（license）管控。修法是把它補進既有的「基礎設施豁免清單」，加一行即可。
授權守門判的是「這個 resource_type 在不在該租戶那張照的 modules 清單裡」，而照只收販售模組。CM-1301 當初為 SMTP／LDAP 建了 INFRASTRUCTURE_MODULES 豁免集合，但 T-1（CM-1390）建 log-forwarding 能力點時漏加進去，於是選單過濾與 API 守門都把它當「沒買」。
失效形狀與 CM-1301 完全同形：能力點都對、route 也對，但功能就是打不開／被標未授權——從症狀很難反推到 license 這一軸，這正是它難查的原因。
common/authz/license.py 的 INFRASTRUCTURE_MODULES 加入 'log-forwarding'，註解沿用既有兩項的格式寫明用途。
commit 46463530（已 push 到 feature/FR-068）
grep 過全部消費端，五處判定點一律走同一個 viewer_licensed_modules()、取同一個 frozenset，沒有第二份清單：
| 消費端 | 用途 |
|---|---|
| common/authz/menu_license_filter.py | 側邊選單過濾 |
| api/auth/routes/ui_route_route.py:_mark_license_flags | 角色矩陣「未授權」標籤的資料來源（就是本卡現象的出處） |
| app/auth/service/role_app_service.py | 角色可授予能力點過濾 |
| app/auth/service/tenant_provisioning_service.py | 開子租戶時的模組扣減 |
| common/enum/grc_job_type_enum.py | 任務型態過濾 |
FE 端 RoleForm.vue 只讀 BE 回的 is_licensed 旗標渲染反灰，不自帶任何清單。故加一處即全數生效，與 CM-1301 當初的「單一真相」設計相符。
判準本身沒問題（「這一項會出現在報價單上嗎？」），漏的是流程——seed 新 resource_type 的人沒有任何提示會想到「還有授權這一軸要處理」。這件事已經漏第二次了（CM-1301 的 SMTP／LDAP、本卡的 log 轉發），所以在三個地方補了提醒：