`result <id>` on a queued/running job reports "No job found" — the still-running message is unreachable when a reference is given

On 1.0.6 (macOS), asking for the result of a job that is still running reports the job as nonexistent:

$ node codex-companion.mjs result task-mrkxdpsi-mij20h --cwd /Users/me/repo
No job found for "task-mrkxdpsi-mij20h". Run /codex:status to list known jobs.
$ echo $?
1
$ node codex-companion.mjs status task-mrkxdpsi-mij20h --cwd /Users/me/repo
- task-mrkxdpsi-mij20h | running | rescue | Codex Task

There is code in resolveResultJob that intends to say Job X is still running. Check /codex:status and try again once it finishes. — but it is unreachable when a job id is passed.

scripts/lib/job-control.mjs (line numbers at current main):

• resolveResultJob (line 256) first calls matchJobReference(jobs, reference, terminalPredicate) with the predicate filtering to completed/failed/cancelled.
• matchJobReference (line 191) applies the predicate, then matches the reference against the filtered list, and throws No job found for "<ref>" (line 210) when nothing matches.
• So for a queued/running job looked up by id, the throw fires inside the first call and the active check at line 269 never runs. The "still running" message is reachable only in the no-reference path, where matchJobReference returns filtered[0] ?? null instead of throwing.

This is worse than a cosmetic wrong message because No job found is the same string the cwd-mismatch case produces. A caller polling result <id> cannot distinguish "wrong workspace" from "not finished yet" from "no such job", and the natural reading — the job does not exist — is the one that is false. We traced a real incident to an orchestrator concluding from this exact string that a dispatched job had never run, and redoing the work while the job was still going.

Possible fixes, either works:

• Make matchJobReference return null when a reference matches nothing, and let each caller produce its own error message (resolveResultJob already has the branching to do this correctly).
• Or in resolveResultJob, match the reference against the unfiltered job list first, then check the status of the match — producing "still running" for active jobs, "No finished job" only when the id genuinely is not in the workspace.

https://claude.ai/code/session_01B5Xst2TXwvPQ5ecfMckbBR

Read scripts/lib/job-control.mjs, starting with matchJobReference and resolveResultJob, then reproduce result for the running job described in the issue. The fix is done when a queued or running reference reports that it is still running, while unknown and wrong-workspace references retain distinct not-found behavior.