compat: treat natural no_tool finish as a complete run

[dappweb]

Summary

Two parity gaps break the stateful react workflow for OpenAI-compatible models that end a task with a plain-text answer instead of a final tool call. Reproduced with a local Qwen3.5-family endpoint (qwen3.8-27b via Ollama /v1).

Changes

1. workflows/stateful_react_agent/_runtime.py — add no_tool to _GRACEFUL_FINAL_STOP_REASONS so force_final_answer() rescue runs when the loop ends naturally after the model has already produced its answer.
2. apodex/task_runner.py — pass no_tool_is_complete=True in the native-workflow completion check, matching the generic-loop path (which already passes it).

Verification

• Before: local qwen3.8-27b-fast completes the task (reads input, writes deliverable content) but the run is reported as run incomplete · stopped_by=no_tool · partial output was not saved as a final report.
• After: same run completes and the final report is rendered/saved.

Notes

• Generic loop already passes no_tool_is_complete=True; this makes the native workflow consistent.
• No behavior change for workflows that finish via explicit final-answer tools.

[zhanghanduo]

Thanks for the attempt to fix.

I think the reported issue is valid, but the root cause is that no_tool is overloaded: depending on the workflow, it can mean a successful plain-text answer, an empty response, a tool-protocol violation, or exhausted nudge retries.

In stateful_react, no_tool_behavior="stop", so a non-empty plain-text response is already a successful final answer. In agent_team, non-empty text is finalized by BareTextFinalizeObserver, while no_tool usually means empty-response retries were exhausted.

Therefore, globally treating no_tool as complete is unsafe, and routing it through force_final_answer() adds an unnecessary LLM call that can rewrite the answer and mark it as best_effort.

I suggest introducing explicit stop reasons such as plain_text_final and empty_response_retries_exhausted, or having each workflow return an authoritative completion status. That would address the root cause instead of making TaskRunner infer completion from the ambiguous no_tool value.