perf(core): resolveLocalizationContext reads its three keys through settings.getMany (#10826)

[os-zhuang]

What

The caller half of #10826 (service half merged as #11200): resolveLocalizationContext prefers onesettings.getMany('localization', [timezone, locale, currency]) over three per-key get()s. Feature-detected — an older service keeps the three parallel gets; a thrown getMany lands in the same direct $in fallback a thrown get did (failed = true, #10221's failure-only cache semantics untouched).

Calibration (the card's own)

The three reads already ran parallel (1 leg), so this is a query-count fix — 16–18/24 collapse to one — not a latency fix.

Serial constraint honored

Landed after #11197 (#10825) on resolve-authz-context.ts, per the domain:engine seat's ruling.

Tests

3 new pins (getMany preferred + per-key get never called + zero direct reads; no-getMany fallback keeps three gets; thrown getMany → direct $in fallback runs once). security/ suite 63/63 in the file, full security dir green, core tsc unchanged vs main. Changeset included.

Closes#10826.

🤖 Generated with Claude Code

[github-actions]

📓 Docs Drift Check

1 anchor(s) derived from 1 changed package(s); no hand-written page names any of them. ✅

What this run could not see

• the SDK route bridge reached 45 of 221 client-bound route-ledger rows — the other 176 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run: node scripts/docs-audit/affected-docs.mjs --bridge-coverage

Coarse fallback — 23 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 21756b3254ed61a6c38baa46642bd003952194b4 → packageMentionDocs.

Which tree this was computed on

This run read content/docs from b002e5f2b3f5b8d0f066abdc790f8ce13bbc8f5e — the merge of head 09f32b428b581c60a6b2e7949a1de25ecbef28a0 into base 21756b3254ed61a6c38baa46642bd003952194b4, which is what actions/checkout gives a pull_request run. Not the PR head.

A worktree cut from an older main holds a different content/docs, so re-deriving there can legitimately return a different list — that is a different tree, not a wrong row. To answer on the same tree:

# while this PR is open — GitHub drops the merge commit once it closes
git fetch origin b002e5f2b3f5b8d0f066abdc790f8ce13bbc8f5e && git checkout b002e5f2b3f5b8d0f066abdc790f8ce13bbc8f5e
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 21756b3254ed61a6c38baa46642bd003952194b4 09f32b428b581c60a6b2e7949a1de25ecbef28a0 && git checkout -B drift-repro 21756b3254ed61a6c38baa46642bd003952194b4 && git merge --no-ff 09f32b428b581c60a6b2e7949a1de25ecbef28a0
node scripts/docs-audit/affected-docs.mjs --json 21756b3254ed61a6c38baa46642bd003952194b4

⚠️ That checkout carried uncommitted changes, so the commit above does not fully identify what was read.

[github-actions]

⛔ merge queue 构建失败 — 先分诊，再决定要不要重排

队列构建 32615751699 红了。队列跑的是全量套件（PR 侧 CI 只跑 affected 子集），
所以失败的测试可能在本 PR 没碰过的包里 —— 那不是重排能修的。每次盲目重排都会让排在后面的所有 PR 重建一轮。

失败的 job（日志抽取，best effort）：

• Test Core (2/6) — 失败步骤: Run this shard's tests

  FAIL test/serve-mcp-capability-collision.e2e.test.ts > #7652: an app loading the MCP client connector still gets the MCP server
  ↳ 失败原因: (这条 FAIL 之后 12 行内没有可识别的原因行 —— 点进 job 看)
  

↳ 失败原因 是判读的关键：超时（Test timed out in … / Hook timed out in …）多半是负载/时序，不是本 PR 的回归；
断言（AssertionError: …）才指向真实的行为改变。两者的 FAIL 行长得一模一样，只有这一行能区分。

跨 PR 相同签名（24h，按失败测试文件聚合）：

• test/serve-mcp-capability-collision.e2e.test.ts — 24h 窗口内只有本 PR 撞到过，暂不汇总（再有一个不同 PR 撞到就会自动开汇总 issue）。
• ⚠️ 24h 评论账本没读完（超过 5 页仍未读到窗口尽头），所以上面的「不同 PR 数」是下界，不是全量。

历史信号：

• 本 PR 过去 24h 无队列失败记录（首次）。
• 过去 24h 队列共有 90 个失败构建（不含本次）。

分诊清单：

1. 失败测试在本 PR 改动的包里 → 真回归，修 PR。
2. 失败测试与本 PR 无关 → 看上面的「跨 PR 相同签名」；已有汇总 issue ⇒ flaky/环境问题实锤，去那张 issue 上谈，修好前重排只会再烧一轮全队列。
3. 两者都不是 → 可能与同组 PR 语义冲突；等前面的 PR 落地或失败出队后再重排一次即可，不要连续重排。

---

Generated by Claude Code · merge-queue-triage workflow (#4859)