fix(plugin-webhooks): ja-JP sys_webhook label renders consistently as ウェブフック

[os-support-ai]

Fixes#12128

What changed

One leaf: packages/plugins/plugin-webhooks/src/translations/ja-JP.objects.generated.ts line 19, sys_webhook.label:

- label: "Webhook",+ label: "ウェブフック",

Triage's ruling (issue #12128, comment by os-trump, 2026-08-25T17:58:36Z): label → ウェブフック, matching the already-repaired pluralLabel and the bundle's own Japanese help prose (object_name.help, triggers.help, both ウェブフック), so sys_webhook renders one way everywhere in ja-JP. This was not my choice to make — the dispatch brief carried the ruling verbatim and my job was landing it without collateral.

Left alone, as fenced by the ruling:

• description (送信 HTTP Webhook サブスクリプション…) — Latin "Webhook" inside Japanese prose about the protocol, a different act from naming the object.
• the Webhook ID field label — an identifier, not the object's own name.
• zh-CN — keeps Webhook for both label and pluralLabel deliberately; there is no established Chinese rendering of the term anywhere in this repo, and Chinese marks no plural, so the singular/plural distinction the source drew doesn't carry over.
• every other locale (en, es-ES) — both internally consistent already (Webhook/Webhooks in both), so out of scope.

How the edit was made

The file's own header says leaf string values are edited in place and that os i18n extract --merge only fills gaps — a present-but-stale translation is not a gap, so the tooling would not have touched this leaf. This is a hand-edit of the leaf string value only; no structural change, no reformatting.

Verification

• pnpm check:i18n — check-i18n-bundles: OK (9 package(s) — all bundles in sync, no undeclared authoring keys), plugins/plugin-webhooks in sync (4 bundle(s)).
• pnpm check:i18n-stale-fill — check-i18n-stale-fill: OK (10 bundle set(s) — no new stale fills, 0 baselined) (scanned 0 stale-fill leaves — confirms the edit didn't strand a new one).
• Full dispatch-derived local gate union (node scripts/pm/dispatch-gates.mjs) run in the foreground against this diff, exit captured before any pipe — all green: check:cross-package-test-inputs, check:page-declaration-shape, check:published-files, check:slot-lookup, check:test-source-alias, check:type-source-resolution, check-ci-filter-parity.mjs, check-comment-mask-adoption.mjs, check-cross-package-test-inputs.mjs, check-plugin-teardown-shape.mjs, docs-audit/check-affected-docs.mjs, docs-audit/check-drift-comment.mjs, plus the changeset family (check:changeset-gate-self-tests, check:objectui-changeset, check-adr-0087-registration.mjs, check-changeset-no-major.mjs, check-empty-changeset.mjs, release-rehearsal-clone.mjs --self-test) and check:nul-bytes.
• @objectstack/plugin-webhooks: pnpm test — 128 passed (128), 11 test files; pnpm typecheck — clean.
• Union re-run at final commit 59c5ec13 (this branch's head).

Changeset

Added (patch, @objectstack/plugin-webhooks) — a shipped translation leaf is user-visible in the Setup/admin UI, so this is not skip-changeset.

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/plugin-webhooks, touching 1 documentable anchor(s).

1 hand-written doc(s) NAME something this change touched and may need an implementation-accuracy re-verification:

• content/docs/automation/webhooks.mdx(via sys_webhook (symbol))

⛔ 2 release-owned page(s) also name something this change touched. These are read-only:

• content/docs/releases/v16.mdx(via sys_webhook (symbol))
• content/docs/releases/v17.mdx(via sys_webhook (symbol))

content/docs/releases/ is RELEASE-OWNED (AGENTS.md "Documentation Guardrails"): release
notes are written centrally at release time, and a code PR that edits them is the exact PR
that guardrail exists to stop. They are still audited — read-only. If one of them is actually
wrong, file an issue or open a dedicated docs-only PR; do not edit it here.

What this run could not see

• the SDK route bridge reached 47 of 219 client-bound route-ledger rows — the other 172 have no registrar path: tail to select them, so pages documenting THEIR client methods cannot appear above, on this or any run. Of those 172: 14 are remediable by widening that discovery convention (an in-repo file declares the path; the convention did not scan it); 56 are structural — on a ledger where NOT ONE row is declared in-repo, so no discovery change reaches them at any price; 102 are undecided (no in-repo declaration, on a ledger that has other in-repo registrars — absence and an unreadable spelling are not distinguishable here). The rows themselves: node scripts/docs-audit/affected-docs.mjs --bridge-coverage
• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 3 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 76c18be8ad56400c85cde381e63c7755bbd6153a → packageMentionDocs.

Which tree this was computed on

This run read content/docs from e533c9135631e89b6d63377c6d20aba9c516e511 — the merge of head 59c5ec138365dd99f5e6f0d7842b0785da9a665d into base 76c18be8ad56400c85cde381e63c7755bbd6153a, 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 e533c9135631e89b6d63377c6d20aba9c516e511 && git checkout e533c9135631e89b6d63377c6d20aba9c516e511
# afterwards, rebuild it from the two parents, which stay fetchable
git fetch origin 76c18be8ad56400c85cde381e63c7755bbd6153a 59c5ec138365dd99f5e6f0d7842b0785da9a665d && git checkout -B drift-repro 76c18be8ad56400c85cde381e63c7755bbd6153a && git merge --no-ff 59c5ec138365dd99f5e6f0d7842b0785da9a665d
node scripts/docs-audit/affected-docs.mjs --json 76c18be8ad56400c85cde381e63c7755bbd6153a

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

Advisory only, and a precision-first one (#9192): a page is listed because it names a
symbol, wire route or SDK method this diff touched — not because it mentions a changed
package. Each row says which anchor put it there, so a wrong row is reportable rather than
merely annoying. To re-verify, run the docs-accuracy-audit workflow scoped to these files:
node scripts/docs-audit/affected-docs.mjs 76c18be8ad56400c85cde381e63c7755bbd6153a → pass the list as
args.docs, on the commit named under Which tree this was computed on.