fix(i18n): add localized verb for the window permission capability

[alectimison-maker]

Summary

• Adds the missing sp.perm.verb.window key to all 23 locales in both Chrome and Firefox trees.
• Adds a regression test asserting every permission-gate capability has a localized verb key in en.js in both trees.

Motivation

The resize_window tool maps to Capability.WINDOW (permission-gate.js:171), and the permission prompt renders t(sp.perm.verb. + cap) (sidepanel.js:9258). No locale defined sp.perm.verb.window, so t() returned the raw key and the consequential-action prompt read: "WebBrain wants to sp.perm.verb.window example.com. Allow it?" — garbled text on a security-critical prompt, in every locale. The next capability added without a verb would hit the same bug silently.

Design

Followed the existing sp.perm.verb.* entry style and inserted the new key next to its siblings. The new test iterates Object.values(Capability) (both trees — Firefox has no dev_patch capability) and requires a non-empty sp.perm.verb.<cap> string in each tree's en.js. The existing all locales cover English keys test then guarantees all 22 non-English locales carry the key.

Testing

• node test/run.js — 1767 passed, 0 failed (1 new test)
• npm run test:security — 60/60 passed
• npm run test:toolbar-guard — 33 passed

Compatibility and risks

• Pure additive dictionary entries; no behavior change for existing locales.
• English value matches CAPABILITY_LABEL[Capability.WINDOW] ("resize the browser window for"), so the prompt reads naturally: "WebBrain wants to resize the browser window for example.com. Allow it?"

[vercel]

@alectimison-maker is attempting to deploy a commit to the esokullu's projects Team on Vercel.

A member of the Team first needs to authorize it.

[esokullu]

Reviewed this alongside #2808, #2813, #2814 and #2815.

The locale rollout looks fine. The azure-openai.js change bundled with it is the issue: it's byte-identical to the one in #2808 (blob 959400a2 in both trees), and both PRs add the same Azure tests to test/run.js from different bases. Whichever merges second will conflict there or leave a duplicated test block behind. Since this PR's subject is the sp.perm.verb.window rollout, dropping the provider change from here and keeping it in #2808 seems like the cleaner split.

The findings against that Azure change are written up in full on #2808. Short version:

• _isNewOpenAIContract() at azure-openai.js:73 matches against this.config.model, which for Azure is the user-chosen deployment name (get deployment(), :21). A deployment named prod-chat backed by o3-mini still sends max_tokens and still gets the 400 the change targets, while o365-assistant on gpt-35-turbo now matches the o3 alternative and sends max_completion_tokens, which the default apiVersion: '2024-10-21' doesn't recognize.
• :72 reads that field untrimmed while get deployment() trims it, so a stray leading space builds a correct URL with the wrong wire contract.
• automaticTokenField() in src/chrome/src/ui/settings.js:2311 gates on config.type === 'openai', so the Compatibility panel keeps reporting max_tokens for Azure deployments that now send max_completion_tokens.

One thing in the locale half worth a look while you're here: permission-gate.js:47 already holds the canonical English verb (CAPABILITY_LABEL[Capability.WINDOW] = 'resize the browser window for') and agent.js:11880 already consumes it with an || 'act on' fallback. Re-typing the same string into locales/en.js:332 gives a security consent string two English sources of truth that can drift apart.

[alectimison-maker]

Done — two changes per your review:

1. Dropped the bundled Azure change. The branch was cut from the Azure PR's base, so it carried azure-openai.js + the Azure tests. It's now rebased onto main and contains only the locale rollout (the Azure fix lives solely in fix(azure): use max_completion_tokens and omit temperature for reasoning deployments #2807).
2. Hardened the consent prompt against the raw-key bug class. renderClarifyCard now falls back to CAPABILITY_LABEL[cap] || cap when a locale lacks sp.perm.verb.<cap>, so a capability added without a locale verb can never render its raw key again — English stays sourced from the single CAPABILITY_LABEL map when the key is absent. The 23-locale sp.perm.verb.window rollout (the actual fix for resize_window) is unchanged, and the regression test now asserts both the CAPABILITY_LABEL coverage and the sidepanel fallback.