feat: add --ephemeral flag to task to avoid polluting Codex Recent

[0dimen]

Problem

Codex Companion's task command always creates a persistent Codex
thread, and this behavior is not changed by this PR — task still
persists by default.

For large or parallel fire-and-forget task runs — especially agent
orchestration workloads that dispatch many independent subtasks —
each task invocation shows up as its own persistent thread in
ChatGPT/Codex Recent, even when the caller only wants the result and
never resumes that particular thread. Persistent history is
unnecessary overhead in that case.

Solution

Add an opt-in --ephemeral flag to task. Existing task
behavior is unchanged.

Existing:
task ...
→ persistent (behavior unchanged)

New:
task --ephemeral ...
→ non-persistent Codex execution

This is a minimal change that reuses the existing persistence
architecture — runAppServerTurn's persistThread option, which
already maps directly to the app-server's ephemeral thread param —
rather than introducing a new thread/session abstraction.

Backward compatibility

• Omitting the flag is byte-for-byte the same code path as before;
  existing task behavior is unchanged.
• --ephemeral is strictly opt-in.
• --resume / --resume-last are untouched and keep working exactly
  as before for persistent tasks.
• --ephemeral combined with --resume/--resume-last is rejected
  with an explicit error — this combination is contradictory, since an
  ephemeral thread was never persisted and cannot be resumed.
• Job records now carry an ephemeral bit so findLatestResumableTaskJob
  never offers an ephemeral run as a --resume-last candidate, and so
  status/result rendering stops suggesting codex resume <id> for a
  thread that was never persisted.

Tests

All 6 newly added tests pass:

• ephemeral does not persist a thread
• default task remains persistent (unchanged)
• 3 concurrent ephemeral tasks stay independent, 0 persistent threads
• ephemeral + --resume rejected
• ephemeral + --resume-last rejected
• an ephemeral task cannot subsequently be resumed via --resume-last

Also manually verified against a real Codex CLI (0.155.1, logged-in
ChatGPT account), reading ~/.codex/state_5.sqlite for a scratch
cwd's persistent thread count:

• task --ephemeral: +0
• task (no flag): +1
• task --resume-last: +0 (resumes the same thread, context intact)
• 3 concurrent task --ephemeral: +0 more
• task --ephemeral --resume-last: validation error, +0

sqlite was used only for read-only verification of the outcome; the
implementation itself does not depend on it and only goes through the
existing/public Codex execution path (runAppServerTurn → app-server
thread/start with ephemeral).

Motivation / use case

Lets an orchestrating agent choose per task:

disposable work   → --ephemeral
resumable work     → existing persistent behavior (default)

so that dispatching many independent, fire-and-forget Codex subtasks
in parallel no longer pollutes Recent/history with threads nobody will
ever revisit or resume.