观察类 finding，来自 #6778 / PR #6831 的实施（该 PR 有意把这一侧排除在外，理由见下）。未认领，不构成派单请求。
事实（origin/main c32944d67 实测）
packages/lint/src/validate-sharing-rule-enforceability.ts:197：
const result = compileCelToFilter(input, { variables: {} });
if (result.ok) return;
// 语法归 validateStackExpressions
if (result.reason === 'parse-error') return;下推编译器有意把 DEFAULT_LIMITS 越界折叠进 reason: 'parse-error'（cel-to-filter.ts:133-138 写明理由：这是每个消费者都已经路由到拒绝路径的 reason）。于是 v17 GA 翻转（CEL_PUSHDOWN_LIMITS_MODE 由 rc-grace 改为 fail-closed）之后，一条语法完美但超出平台解析预算的 sharingRules[].condition：
- 在
validateSharingRuleEnforceability 里走到上面这行 return，一条都不报；
- 规则本身在 boot 时会被
bootstrapDeclaredSharingRules 跳过（不写 sys_sharing_rule，不产生任何 sys_record_share 授权），只留一行 boot WARN。
即：声明了一条分享规则，它什么也不授予，而 enforceability 门对此沉默。
与 #6778 的区别（为什么 PR #6831 没有顺手一起改）
#6778 的缺陷形状是贴错标签：RLS 侧确实报了，但报在 rls-predicate-unparseable 名下，提示语讲 SQL 与 CEL 的方言混淆。分享侧的形状是让渡：它不报错 id，而是有意不报，把语法交给 validateStackExpressions。二者不是同一个缺陷在两个入口，因此 #6778 的「同样的输入照样被拒，只是说对话」这一无行为变更口径，不能原样套到这里。
要修就得先回答：越界是否应当停止让渡给 validateStackExpressions？那会改变「哪条规则报某个输入」，且 validateStackExpressions 覆盖全栈每一条 CEL 表达式，不止 sharingRules——是一个比 #6778 大一档的面。
未验证的相邻问题（留给分诊，本 finding 未测）
validateStackExpressions 在越界时具体说什么、是否也按语法口径措辞，本次没有测量。若它同样按语法说话，那这条 finding 的实际用户影响会比「只是沉默」更大一些。
为什么是观察类而非缺陷
翻转尚未发生（cel-pushdown-limits.ts:75 当前为 'rc-grace'），宽限窗口内越界 condition 仍被放行并编译，所以今天没有用户会撞上。严重度按 #4949 的口径交由分诊轮评级，不在此自行判定。
Refs: #6778、PR #6831（RLS 侧的对应修复）、#6132 / PR #6766（GA 开关的来源）
观察类 finding，来自 #6778 / PR #6831 的实施（该 PR 有意把这一侧排除在外，理由见下）。未认领，不构成派单请求。
事实（
origin/mainc32944d67实测）packages/lint/src/validate-sharing-rule-enforceability.ts:197：下推编译器有意把
DEFAULT_LIMITS越界折叠进reason: 'parse-error'（cel-to-filter.ts:133-138写明理由：这是每个消费者都已经路由到拒绝路径的 reason）。于是 v17 GA 翻转（CEL_PUSHDOWN_LIMITS_MODE由rc-grace改为fail-closed）之后，一条语法完美但超出平台解析预算的sharingRules[].condition：validateSharingRuleEnforceability里走到上面这行return，一条都不报；bootstrapDeclaredSharingRules跳过（不写sys_sharing_rule，不产生任何sys_record_share授权），只留一行 boot WARN。即：声明了一条分享规则，它什么也不授予，而 enforceability 门对此沉默。
与 #6778 的区别（为什么 PR #6831 没有顺手一起改）
#6778 的缺陷形状是贴错标签：RLS 侧确实报了，但报在
rls-predicate-unparseable名下，提示语讲 SQL 与 CEL 的方言混淆。分享侧的形状是让渡：它不报错 id，而是有意不报，把语法交给validateStackExpressions。二者不是同一个缺陷在两个入口，因此 #6778 的「同样的输入照样被拒，只是说对话」这一无行为变更口径，不能原样套到这里。要修就得先回答：越界是否应当停止让渡给
validateStackExpressions？那会改变「哪条规则报某个输入」，且validateStackExpressions覆盖全栈每一条 CEL 表达式，不止sharingRules——是一个比 #6778 大一档的面。未验证的相邻问题（留给分诊，本 finding 未测）
validateStackExpressions在越界时具体说什么、是否也按语法口径措辞，本次没有测量。若它同样按语法说话，那这条 finding 的实际用户影响会比「只是沉默」更大一些。为什么是观察类而非缺陷
翻转尚未发生（
cel-pushdown-limits.ts:75当前为'rc-grace'），宽限窗口内越界 condition 仍被放行并编译，所以今天没有用户会撞上。严重度按 #4949 的口径交由分诊轮评级，不在此自行判定。Refs: #6778、PR #6831（RLS 侧的对应修复）、#6132 / PR #6766（GA 开关的来源）