fix(platform-objects): sys_job_run description says history, not audit trail

[os-elon]

Fixes#9735

What

sys_job_run is job run history, not the audit trail (binding ruling on #9633:
sys_audit_log is the separate audit surface, with its own opt-in, writer and
retention). The object's own header comment already said so
(sys_job_run — Background Job Execution History), but its description field —
the user-facing copy Studio/Setup surfaces, and the string that propagates into the
generated translation bundle — still called it "Background job execution audit trail".

• packages/platform-objects/src/audit/sys-job-run.object.ts: description changed
  from 'Background job execution audit trail' to 'Background job execution history'.
• packages/platform-objects/src/apps/translations/en.objects.generated.ts:
  regenerated via node scripts/check-i18n-bundles.mjs --write (never hand-edited) —
  the single echo of the same string, at what was line 2375.

Out of scope (untouched, by design)

• sys_audit_log and every other object's copy.
• The zh-CN translation (后台任务执行审计记录) still reads "audit" — the
  extract/merge keys by schema path, not by source-text hash, so an unrelated-locale
  human translation isn't invalidated by an English source edit. Already tracked by
  the open i18n: a corrected source description never reaches an already-translated locale, and no gate can tell the stale translation from a current one #9672 (i18n: a corrected source description never reaches an
  already-translated locale) — not re-filed, not fixed here.
• content/docs/releases/v14.mdx (docs-drift advisory hit): mentions sys_job_run
  only for its 30d retention window, not its description copy — read, negative,
  untouched (and out of bounds for a code PR either way).

Tests

See the dev report posted on #9735 (commit c32fda0).

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

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

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

• content/docs/releases/v14.mdx(via sys_job_run (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

• 1 name(s) were too generic to anchor anything (single lowercase words)

Coarse fallback — 2 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 e9534a4acab63aa91a67dfb76110b6695be68df0 → packageMentionDocs.

Which tree this was computed on

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

⚠️ 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 e9534a4acab63aa91a67dfb76110b6695be68df0 → pass the list as
args.docs, on the commit named under Which tree this was computed on.