Support immediate re-triggering of completed tasks before TTL cleanup

[axon-agent]

Background

When a TriggerComment is posted on an issue that already has a completed (but not yet TTL-evicted) Task, the spawner currently skips creating a new task because one already exists. This is the same behavior as the existing label-based flow — once a task is created for an issue, it won't be re-created until TTL cleanup removes it.

This came up during review of #420 (comment-based workflow control). The comment filter correctly identifies the issue for processing, but the spawner deduplication logic prevents re-creation.

Desired Behavior

Allow users to re-trigger work on an issue immediately, without waiting for TTL cleanup. This is not specific to comment-based control — it applies equally to label-based flows.

Possible Approaches

1. A new field like retriggerPolicy: "DeleteCompleted" — tells the spawner to delete completed tasks when they re-appear in discovery results
2. Appending a counter/suffix to task names (e.g., spawner-1-v2) — but this complicates the naming convention

Context

• Discussed in: https://github.com/axon-core/axon/pull/420#discussion_r2853576131
• Current behavior is acceptable for the initial comment-based workflow implementation

[gjkim42]

Proposal: Implicit retrigger via TriggerComment timestamp comparison

Rather than introducing a new retriggerPolicy field, retriggering can be built into the existing TriggerComment mechanism — it's the only source that provides a clear "new intent" signal.

Why not a separate retriggerPolicy field?

• Cron: No user signal, time-based only — retrigger doesn't apply.
• Label-only GitHubIssues: The label stays on the issue, so every poll cycle would look like a retrigger. No way to distinguish "retrigger" from "still discoverable."
• Jira: Same problem as labels.

A top-level or TaskSpawnerSpec-level policy would be too broad. Placing it on GitHubIssues next to TriggerComment is more accurate, but at that point it's just describing how TriggerComment should naturally behave.

Proposed behavior

When TriggerComment is set and the spawner finds a completed task for a discovered item:

1. Check if there's a trigger comment posted after the existing task's status.completionTime.
2. If yes → delete the completed task, create a new one.
3. If no → skip (current dedup behavior).

This means:

• No new API fields needed — the retrigger behavior is implicit when using TriggerComment.
• TTL still serves its purpose for observability (completed tasks stick around until TTL or retrigger).
• Label-based and Cron flows are unaffected.
• The source needs to pass the latest trigger comment timestamp alongside each work item so the spawner can compare it against completionTime.

[gjkim42]

let's make it a default behavior and make retriggerPolicy when we need it