[dotnet-port-api] Port TodoCompletion and BackgroundTaskCompletion loop evaluators (placement decision) #1163

Following #1162 (AI-judge loop evaluator), the remaining .NET loop evaluators Go still lacks are TodoCompletionLoopEvaluator and BackgroundTaskCompletionLoopEvaluator (DelegateLoopEvaluator is already covered by Go's loop.EvaluatorFunc). Filing issue-first because there is a real placement/coupling decision.

The gap

TodoCompletionLoopEvaluator keeps re-invoking the agent until a TodoProvider has no remaining todos (optionally only while in one of a configured set of agent modes), continuing with feedback listing the remaining items ({remaining_todos}).

The Go design question

.NET resolves the TodoProvider (and AgentModeProvider for the mode gate) at evaluation time from the agent via GetService<T>(). Go has no equivalent — loop.Context exposes InitialMessages, LastResponse, Options, Iteration; the session is reachable via agent.GetOption(ctx.Options, agent.WithSession), but there is no provider-resolution mechanism. So the Go evaluator must take an explicit *todo.Provider (and, for modes, an *agentmode.Provider).

That raises a placement decision, because agent/harness/loop currently imports no sibling harness package:

1. In loop — mirrors .NET's namespace, but introduces loop → todo (and loop → agentmode) dependencies.
2. In todo — keeps loop dependency-free; todo imports the loop.Evaluator/Evaluation types (no cycle, since loop does not import todo). Arguably more idiomatic for Go.

I lean toward option 2 (evaluator lives in todo, e.g. todo.NewCompletionLoopEvaluator(p, ...)), keeping the loop package free of harness-specific deps, but this is the maintainers' call. Happy to implement whichever placement you prefer — the logic itself (remaining-todos check + {remaining_todos} feedback + optional mode gate) is straightforward and I have the .NET reference. Same question applies to BackgroundTaskCompletionLoopEvaluator.