Replace /reset-worker workflow with TriggerComment-based retrigger

Summary

The /reset-worker GitHub Actions workflow (.github/workflows/reset-kelos-worker.yaml) can be replaced by the spawner's TriggerComment retrigger feature (#432), but there's a blocker: the kelos/needs-input excludeLabel prevents the spawner from even discovering issues that need retriggering.

Current flow

1. Spawner discovers issue (no kelos/needs-input) → creates task
2. Agent finishes → adds kelos/needs-input label
3. Human posts /reset-worker → workflow removes label + deletes task via kubectl
4. Next poll cycle → spawner rediscovers the issue and creates a new task

Problem

TriggerComment retrigger (#432) can delete completed tasks and recreate them, but excludeLabels: [kelos/needs-input] filters out the issue at the GitHub API level before the spawner ever sees it. The trigger comment is never evaluated.

Proposal

Teach the spawner to remove the kelos/needs-input label (or a configurable excludeLabel) when it retriggers a completed task. This would let TriggerComment fully replace the /reset-worker workflow:

1. Human posts trigger comment (e.g., /kelos pick-up)
2. Spawner discovers the issue (label no longer blocks discovery for retrigger)
3. Spawner deletes the completed task, removes the excludeLabel, and creates a new task

Considerations

• The kelos/needs-input label is also used by kelos-triage.yaml — changes should not break that flow
• /reset-worker also resets running tasks; TriggerComment only handles completed ones
• Admin-only access control on /reset-worker would be lost unless replicated

Start by reading .github/workflows/reset-kelos-worker.yaml and tracing the spawner's TriggerComment handling and excludeLabels behavior. Review kelos-triage.yaml before changing label handling. Done means completed-task retriggering can remove the configured exclude label without breaking triage, running-task behavior, or the existing admin access expectations.