feat(config): add payload disable controls to the visual editor

[xwil1]

Summary

• add persisted disable toggles for payload rules, params, and filter entries in the visual config editor
• keep disabled values visible while making disabled inputs render as greyed-out, non-interactive controls
• align visual validation and YAML round-trip behavior with the backend payload disable semantics, and add focused local tests for the parsing/serialization logic

Backend dependency

The matching backend support has already been submitted in router-for-me/CLIProxyAPI#2741.
This UI change can wait for backend feedback first if you prefer to review the behavior end-to-end after the backend shape is confirmed.

Why

The backend now supports keeping experimental payload rules in YAML while temporarily ignoring them. This frontend PR exposes that workflow directly in the management UI so debugging no longer requires repeatedly deleting and rebuilding test rules.

UI changes

• add rule-level and param-level disable/enable actions for payload rewrite sections
• add filter entry disable/enable actions so filter rules can be tuned without deleting entries
• show disabled badges and disabled card styling to make the state explicit
• switch disabled text fields, textareas, and selects to a greyed-out non-interactive state
• keep the two-line payload param layout and update button labels to concise Chinese text (启用 / 禁用)

Local validation

• Run npm run type-check
• Run npm run build
• Run the focused local test bundle for src/hooks/useVisualConfig.test.ts
• Verify the UI changes locally against the backend behavior

[gemini-code-assist]

Code Review

This pull request introduces the ability to disable specific payload rules and parameters within the visual configuration editor. Key changes include updates to the data models and YAML serialization/deserialization logic to support a disabled-params field, alongside UI enhancements such as disabled state styling, toggle buttons, and status badges. The PR also prevents switching to the source tab when validation errors exist and adds comprehensive tests for the new functionality. Review feedback focuses on reducing CSS duplication by consolidating identical badge styles.

[gemini-code-assist]

The styles for .payloadParamStateBadge are identical to .ruleStateBadge defined earlier in this file. To improve maintainability and reduce code duplication, you can remove this class and use .ruleStateBadge in its place.

[gemini-code-assist]

To avoid CSS duplication, you can reuse the existing .ruleStateBadge class here, as it has identical styles to .payloadParamStateBadge.

Suggested change

	<span className={styles.payloadParamStateBadge}>
	<span className={styles.ruleStateBadge}>

[gemini-code-assist]

To avoid CSS duplication, you can reuse the existing .ruleStateBadge class here, as it has identical styles to .payloadParamStateBadge.

Suggested change

	<span className={styles.payloadParamStateBadge}>
	<span className={styles.ruleStateBadge}>

[LTbinglingfeng]

这版我先给 Request changes，有一个我认为会影响该功能目标的阻塞点。

1. src/pages/ConfigPage.tsx 现在在切换到 source tab 时，只要存在 payload 校验错误就直接拦截；同时 src/hooks/useVisualConfig.ts 的 hasPayloadParamValidationErrors() 仍然把 disabled rule / disabled param 里的非法值当成阻塞错误。

这和 PR 描述里的目标不一致。这个 PR 的核心卖点是“把实验性 payload 规则保留在 YAML 里，但临时禁用，不需要反复删除/重建”。按现在的实现，用户一旦把一个未完成或暂时无效的参数标成 disabled，仍然会被卡住：既不能正常走可视化保存，也不能切回 source tab 手工修 YAML。实际体验上相当于“看起来支持 disabled，实际上 disabled 仍然不能脱离校验约束”。

我建议至少保证其中一条成立：

• disabled 项不参与这类前端阻塞校验；或
• 即使继续校验，也不要阻止用户切回 source tab 进行手工修复。

如果后端语义明确要求 disabled 项也必须始终合法，那也建议把前端文案和交互重新收紧，不然当前行为和这个 PR 的功能描述是冲突的。

其余像样式复用/测试接线之类的问题我认为都不是这轮的主要 blocker，先把这个行为语义理顺更重要。

[xwil1]

@LTbinglingfeng 感谢指出，这个 blocker 已在 d577eaa 修复。

这次按你建议走了“disabled 项不参与前端阻塞校验”这条语义：

• hasPayloadParamValidationErrors() 现在会跳过 disabled rule / disabled param，不再把它们计入前端阻塞校验。
• 因此未完成或暂时无效、但已经 disabled 的 payload 项，不会再阻塞可视化保存，也不会再阻止切回 source tab。
• enabled 的非法参数仍然会继续阻塞，避免把正常校验语义一起放松掉。

已复核：

• 聚焦测试：src/hooks/useVisualConfig.test.ts（补了 disabled rule / param 不再阻塞、enabled invalid param 仍阻塞的覆盖）
• npm run type-check
• npm run build

另外后端 PR router-for-me/CLIProxyAPI#2741 也已经补齐修复并更新，目前在等待 reviewer 复核。麻烦你有空时再帮忙看一眼，谢谢。