Unknown task should not error workflow

[neekolas]

When processing a comment where there is no task associated, we should not fail the workflow. If coder.findTaskByName returns null, we should set located to null in src/workflows/steps/comment.ts and then abort the rest of the workflow.

That way we don't have to see errors on what is otherwise benign behavior.

[xmtp-coder-tasks]

Task completed.

[xmtp-coder-agent]

Bugfix spec — issue #116: Unknown task should not error workflow

Current Behavior

In src/workflows/steps/comment.ts, the locate-task step throws
NonRetryableError when coder.findTaskByName(taskName) returns null:

const located = await step.do("locate-task", async () => {
    const raw = await coder.findTaskByName(taskName);
    if (!raw) {
        throw new NonRetryableError(`task ${taskName} not found`);
    }
    // ...
});

Because this is uncaught in runComment, the workflow instance transitions to
errored. This surfaces in wrangler workflows instances list and Workers
Logs as a failure, even though the root cause — a comment posted on an
issue/PR that has no Coder task associated with it — is benign and expected
(e.g. a comment on an issue that was never assigned to the agent).

Related: src/workflows/steps/failed-check.ts already handles the same
"no task exists for this change" case correctly by returning null from the
locate-task step and short-circuiting the workflow without error.

Expected Behavior

runComment should match the pattern used in runFailedCheck:

• When coder.findTaskByName(taskName) returns null, the locate-task
  step returns null instead of throwing.
• runComment checks for this and returns early (no react-to-comment, no
  ensureTaskReady, no send-task-input) — the workflow completes
  successfully, not as errored.
• No GitHub comment is posted about the skip; it is silently a no-op, the
  same as the existing "PR comment with no linked issue" short-circuit at
  comment.ts:86–91.

Unchanged Behavior

• When the task IS found but its projected scalars (id / owner_id) are
  the wrong type, locate-task must still throw NonRetryableError. That
  failure mode indicates an upstream SDK-shape regression and should remain
  loud.
• The PR-with-no-linked-issue short-circuit at comment.ts:86–91 is
  unchanged.
• The reaction / ensureTaskReady / sendTaskInput sequence for the
  happy path is unchanged.
• Other workflow steps (create-task, close-task, failed-check) are
  unchanged.
• Step ordering and names within runComment are unchanged for the happy
  path, so existing step-ordering assertions continue to pass.

Test impact

src/workflows/steps/comment.test.ts contains one test that asserts the
current (buggy) throw behavior:

test("throws NonRetryableError when task not found (PR path)", ...)

This must be rewritten to assert the new behavior: the workflow short-circuits
silently — no react-to-comment, no send-task-input, no thrown error — and
step.calls stops after locate-task (with find-linked-issues preceding
for the PR path).

An additional test for the issue-kind path (no PR, direct issue comment on an
unknown task) should be added to cover the primary case described in the
issue.