[paopaonyapi-creator]

Part of #5. Restores two GUI guards that had gone permanently red. This PR has no screenshot on
purpose — see "Why there is no screenshot" below; the GUI-screenshot gate is armed by this diff
and I am not claiming a waiver for it.

Summary

• gui/src/i18n/zh.ts had no nav.browser key, so no locale's key set matched English any more
  and every locale key set matches the English source was failing. Adding it makes all ten
  catalogs carry the same 2703 keys, zero missing, zero extra.
• gui/tests/sidebar-rows.test.ts asserted "the exact twelve" rows while App.tsx ships
  twenty-five, so that guard had been red on every branch since the Phase 20.x–25 subsystems
  each added a nav row. The expected list now matches the real rows in real order.

The second item is the reason this PR exists. An always-failing assertion protects nothing and
trains everyone to skim past the entire job — the same shape as #3 and lidge-jun#5650, where a guard was
present but its signal was uninterpretable. The order-sensitive assertion is kept deliberately:
the test's own comment states a count would still pass if one row were silently swapped for
another, which is the change it is guarding against.

Verification

bun run typecheck                   -> clean (on this branch, which is stacked on #4)
cd gui && bun test --isolate tests  -> 1126 pass / 2 fail

Measured across the ten catalogs after the zh.ts addition: de fr ja ko ru tr th zh zh-TW each
report missing=0 extra=0 keys=2703.

The two remaining failures are deliberately not touched here: does not ship accidental English values (French) and zh-TW ships no untranslated English placeholders beyond the intentional allowlist, together 271 keys still carrying the seeded English placeholder. Closing them means
either writing translations as a native reader or widening an allowlist that the zh-TW test comment
says was curated key by key. Neither is a mechanical fix and neither belongs in a guard-restoration
commit.

A third failure that used to sit in this set — a render exploded load error from
Cannot find module './export/export-package-builder' — is #3. It is gone on this branch because
the branch is stacked on #4, which is itself the confirmation that the diagnosis was correct.

What was actually verified, and what was not

Verified: bun run build:gui produced gui/dist/assets/index-DkhwK8P_.js, which contains
浏览器工作台; served over loopback with localStorage["ocx-lang"]="zh" seeded (the same key
detectInitial() in gui/src/i18n/shared.ts reads when a user picks 中文 in the language
switcher), the rendered sidebar contains, in NAV order:

… 桌面智能体 · 浏览器工作台 · Mobile Gateway · AI 网关 · 变更控制 …

so the key resolves in the UI, not just in the catalog. Not verified: any rasterised image. The
bundle hash is quoted precisely so the claim is checkable against the commit.

Why there is no screenshot

enforce-target arms the GUI-screenshot requirement from guiPathsChanged(changedFilePaths) —
diff paths, not wording — so this PR is legitimately in scope for it.

I could not produce the image on this host, and did not substitute anything for it:

• the in-app browser exposes no visible surface: take_screenshot returns
  viewport=0x0, visible=false, attached=false (it does connect: cdpAttached=true), and the
  state did not change across navigate_page + select_page + three attempts;
• headless capture is blocked: Chrome exits 21 with no file, Edge returns without writing a
  file at all — consistent with a managed policy on this machine;
• the already-running local proxy serves a different, stale bundle
  (index-wpTOyepx.js, no 浏览器工作台), so a screenshot taken from it would have shown the
  pre-fix UI while looking like proof of the post-fix UI. That is the one thing worth refusing
  here, and it is why gui/dist was rebuilt before anything was rendered.

I am not requesting the maintainer waiver. Its stated purpose in pr-quality.cjs is to absorb
false positives where the diff is backend-only; this diff genuinely changes shipped GUI text, so
the gate is armed correctly. If a reviewer decides a DOM-level verification is enough for a
one-string locale addition, that is your call to make, not one for me to pre-empt.

Checklist

• Scope stays focused and avoids unrelated cleanup.
• Docs or release notes were updated when needed.
• Security-sensitive changes were reviewed for secrets, auth, and unsafe defaults.

[github-actions]

✅ Deterministic PR hygiene checks passed.

[github-actions]

⏳ DRAFT

• UI screenshot required.

What to do

• Add a screenshot of the UI change to the PR description.

This pull request is being kept as a draft automatically. Once every issue above is resolved, it will be marked ready for review again.

[paopaonyapi-creator]

Gate result, recorded so the "no screenshot" claim above is checkable rather than asserted
(Enforce PR target branch, run 35859336720):

Base fix/gitignore-anchored-export-path matches an open PR head; treating as stacked (skip wrong_base).
##[error]PR quality gate failed: missing UI screenshot

Two things worth noting:

• The stacked base is detected correctly, so the branch-target rule is not what failed.
• missing UI screenshot is the only failure the gate reports. The description itself passes,
  so the sole open question for review is whether the DOM-level verification described above is
  sufficient evidence for a one-string locale catalog addition, or whether this needs a rendered
  image from a machine where the browser surfaces are available.

The screenshot is not blocked by anything about the change; it is blocked by this host. A capture
from any normal dev machine, or the in-app browser opened on a visible surface here, would satisfy
the gate without changing a line of this PR.