fix(spec): IJobService JSDoc names sys_job_run as job run history, not the audit trail (#9673)

[os-elon]

Fixes#9673

What

packages/spec/src/contracts/job-service.ts called the storage written by
replay() and JobRunOutcome.reason "the execution audit trail" / "an audit
surface" in three spots. The binding #9633 ruling: sys_job_run is job run
history, not the audit trail — sys_audit_log is the audit surface, with
its own opt-in, writer and retention. This PR fixes the wording; it changes
no behavior.

Three spots fixed (grepped the whole file for "audit" — these were the only
sys_job_run-pointing instances):

• JobRunOutcome.reason block-comment description: "free text for an audit
  surface" -> "free text for run history"
• JobRunOutcome.reason field JSDoc: "for the audit trail" -> "for job run
  history"
• IJobService.replay?() JSDoc: "records that this run is a replay in the
  execution audit trail" -> names sys_job_run as job run history vs.
  sys_audit_log as the audit surface, and adds the caveat IJobService.replay's spec JSDoc calls sys_job_run "the execution audit trail" — the exact conflation the #9633 ruling rejected #9673 suggested —
  recording anything durable depends on an adapter that persists run history
  at all (e.g. DbJobAdapter's recordRuns option), since DbJobAdapter.replay() writes its synthetic sys_job_run row regardless of recordRuns — an operator who switched run history off still accumulates replay rows #9633 made that
  conditional where the prose previously read as unconditional.

Out of scope

packages/platform-objects/src/audit/sys-job-run.object.ts:32 — the
sys_job_run object's own description field says "Background job
execution audit trail" (same conflation, user-facing Studio copy this time).
Outside this PR's one-file scope per dispatch; filed as #9735.

Regeneration

gen:schema, gen:openapi and gen:docs were run (products-follow-source);
none produced a diff — contracts/*.ts holds hand-written TS service
interfaces, not .zod.ts schemas, so this JSDoc-only change doesn't feed any
generator. check:generated and check:docs both pass, re-verified at head
ae3240e.

Tests

Full command output is in the report comment on #9673. Summary: @objectstack/spec
typecheck clean; vitest run 413 files / 10972 tests passed; all locally
derived gates (node scripts/pm/dispatch-gates.mjs) green at head ae3240e.

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

This PR changes 1 package(s): @objectstack/spec, touching 2 documentable anchor(s).

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

• content/docs/kernel/contracts/index.mdx(via IJobService (symbol))

What this run could not see

Coarse fallback — 115 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 e196c6a9baa8684c14e5e72545c8009f98a9ed14 → packageMentionDocs.

Which tree this was computed on

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

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