GitLab

在前一个 commit 的 isResponsesShape 短路路径基础上,补充对 Cursor 云端
带过来的、Codex 上游统一不支持的顶层 Responses API 参数的剥离:

  - prompt_cache_retention
  - safety_identifier
  - metadata
  - stream_options

根因补充:这条 raw-body 透传路径为了保留 Cursor 的 input 数组整体结构,
不再经过 ChatCompletionsRequest 的反序列化过滤,所以这些 Go 结构体里
没有对应字段的参数会被原样发到上游,上游返回:
    Unsupported parameter: <field>
常规 Chat Completions 转换路径天然通过 ChatCompletionsRequest 丢弃未知字段,
不受影响;此处仅在 isResponsesShape 分支内用 sjson.DeleteBytes 显式过滤,
作用域最小。剥离列表与 openai_gateway_service.go:2034 的
unsupportedFields 语义对齐。

另外在 applyCodexOAuthTransform 的 OAuth 兜底 strip 列表里同步追加
prompt_cache_retention,作为对该函数所有其他 OAuth 调用点的 defense
in depth(当前只有 Cursor 路径的短路已在前面剥过,但保留这一层更稳)。

测试:
- TestCursorMixedShape_StripsUnsupportedFields — 验证所有 4 个字段都被剥
- TestApplyCodexOAuthTransform_StripsPromptCacheRetention — OAuth 兜底路径
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Cursor 云端 (User-Agent: Go-http-client/2.0) 发往 /v1/chat/completions 的
body 使用 Responses API 格式:
    {"model":"gpt-5.4","input":[{"role":"system","content":"..."}],"stream":true}

原代码用 ChatCompletionsRequest 反序列化,该结构体没有 Input 字段,
Cursor 的 input 数组被静默丢弃,ChatCompletionsToResponses 转换后产出
input: null,Codex 上游以 "Invalid type for 'input': expected a string,
but got an object" 拒绝请求(上游 typeof null === 'object')。

修复:在 ForwardAsChatCompletions 里用 gjson 检测 body shape,当 input
存在且 messages 缺失时,跳过 Chat→Responses 转换,用 sjson 仅改写 model
字段后原样透传 body。billing 所需的 ServiceTier 和 Reasoning.Effort 通过
gjson 从 raw body 提取,下游 codex OAuth transform 路径保持不变。

测试:新增 openai_cursor_warmup_pipeline_test.go,覆盖 5 个 shape 检测
用例(正向/标准请求不误伤/两字段共存/空 body/JSON 回读)。
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

 fix: 修复多个 UI 和功能问题 - 表格排序搜索、导出逻辑、分页配置和状态筛选

fix: 同步 LoadFactor 到调度快照缓存

feat: 为openai分组增加messages调度模型映射并支持instructions模板注入

fix(ops): 将错误日志请求体存储限制从 10KB 提升至 256KB

fix: include home_content URL in CSP frame-src origins

feat(auth): support OIDC login and prefer IdP real email on sign-in

LoadFactor 字段在构建调度快照缓存时缺失，导致调度算法
EffectiveLoadFactor() 无法使用配置的负载因子，回退到 Concurrency。
这会影响账号的负载率计算，进而影响调度优先级。

修复：在 buildSchedulerMetadataAccount 中添加 LoadFactor 字段。

10KB is too aggressive for modern LLM API requests where conversation
context routinely exceeds 1MB. This causes error logs to contain only
a minimal placeholder, making it impossible to debug upstream failures.

256KB retains enough context for effective debugging while the existing
multi-pass trimming logic handles larger payloads gracefully.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

问题原因：
原本的 `style.css` 代码全局使用了 W3C 标准属性 (`scrollbar-width`)。而在 Chrome 121+ 以及 Safari 环境下，一旦匹配到 W3C 标准属性，浏览器就会放弃 WebKit 的定制样式，全面交由操作系统原生渲染。因为 macOS 原生的滚动条特性就是“不滚动时自动隐藏”，加之原本又配置了全局 hover 时才显色的透明度逻辑，最终导致在苹果系统下数据表常常无法明显看出横向滚动条。

修复方式：
1. 在 `style.css` 中增加 `@supports (-moz-appearance:none)`，将对全局 `scrollbar-width` 的干预严格隔离限制在 Firefox 浏览器内，防止误伤 Chrome 等 WebKit 系浏览器。
2. 移除旧版代码中对 `.table-wrapper` 直接定义的 `scrollbar-width` 和透明覆盖。
3. 在 `DataTable.vue` 内部，通过 `!important` 将 Webkit 专属定制外观（12px高度，实心圆角灰色轨道）的优先权推至最高，强制覆盖透明隐身规则。
4. 为底层 table 添加了 `min-w-max` 属性，强制阻止内容宽度受限于屏幕边界带来的收缩，充分保证合理超出范围而触发常驻横向溢出。

优化调度快照缓存，避免 1.5 万账号场景下 Redis 大 MGET