ob audit renders every sealed job run as an unnamed deploy that succeeded

[vishr]

What happens

ob audit renders every sealed job run as an unnamed deploy that succeeded.
Given a job_run journal, the row comes out as:

action="job"  outcome="deployed"  target=""

Three separate defects produce that:

• Action. auditAction has no "job" case, so Phase: "job" falls through
  to the default and returns the phase verbatim — "job" rather than
  "job run" (internal/engine/audit.go:172-186).
• Outcome. auditOutcome likewise has no case, and its default is
  "deployed" (internal/engine/audit.go:189-207). A job that ran is reported
  in the vocabulary of a deploy.
• Target is empty. The job name is written to Record.Service
  (internal/engine/job.go:84, :91), but auditRows only lifts Target
  (internal/engine/audit.go:146-151), and AuditRecord has no Service
  field at all (:51-63). So the name never reaches the row.

The RELEASE column is also misleading: it shows the operation id
(<ts>-<sha>-job_run-<nonce>, internal/onebox/service.go:58-63), not the
release the job actually ran against.

Why it matters

ob audit is the only review path that shows sealed job runs at all — ob job
has no read commands, and ob schedule history refuses a non-scheduled job
(internal/engine/schedule_history.go:98-108). So for a destructive or
migration job the single available after-the-fact view reports that a job of
unknown name "deployed". ob audit is also what the operation_failed and
cancelled error codes name as the next command, which is exactly when someone
is trying to work out what ran.

Expected

ACTION reads job run <name>, and OUTCOME uses a job-appropriate term
(succeeded / failed) rather than deployed.

Suggested fix

• Add case "job": return "job run" to auditAction.
• Add a job case to auditOutcome returning succeeded (and the existing
  failure handling for a failed run).
• Lift Service into AuditRecord and into the row when
  OperationKind == "job_run", so the name renders.

Whether the RELEASE column should show the release the job ran against rather
than the operation id is a separate call — the release is currently journaled
only as free text in Detail (internal/engine/job.go:85), which #166 covers.

Scope and safety

Read-only rendering change. No effect on what is recorded, on the journal
format, or on execution. Existing journals render correctly after the fix
because the data is already present — only the projection is wrong.

Found while verifying #166, which needs this path to work as its documented
fallback. The two are independent: this is a bug in ob audit and stands on its
own.