Require explicit work orders before auto-starting tasks

[mikemikimike]

Summary

• Require a direct, non-question work order in both route judgments before automatically starting a task.
• Prevent a stopped task's result wake from starting the same request again, while keeping a new human message eligible for normal judgment.
• Clarify task routing behavior in the chat manual and add regression coverage for both cases.

Validation

• go build ./... passed.
• gofmt -d internal/session/route_judge.go internal/session/route_judge_test.go produced no diff.
• go vet over the Windows production sources in internal/session passed.
• go generate ./internal/manual passed.
• go test -count=1 ./cmd/codeaf-changes passed.
• go test -count=1 -p 2 -timeout=15m ./... fails on existing Windows-incompatible test sources and platform assumptions; the same command also fails on clean dev.
• The ordinary internal/session test package cannot build on Windows because existing tests depend on Unix-only packages and syscalls.

Fixes #1804

#1804

[ZeroPoint95]

@mikemikimike, the unwanted starts and stopped-task respawn reported in #1804 are worth fixing, and the stopped-result guard makes sense. I’m requesting a change to the routing rule before merging.

The shared prompt currently says: Every question is false, including "can we..." and "could you...". That treats being a question and being a request to act as mutually exclusive, even though both can be true:

• “Could you fix the failing tests?” is both a question and a request to act
• “Can you implement headless screenshots and add tests?” is likewise both a question and a clear request to act
• “How would headless screenshots work?” asks for an explanation
• “Can we get screenshots without a display?” is ambiguous without context and should not automatically start work
• “We should support screenshots eventually” expresses future direction, not authorization to begin

Please distinguish requests to perform work now from feasibility questions, discussion and brainstorming, rather than requiring a non-question grammatical form. Clear polite requests should remain eligible for normal task routing; ambiguous messages should stay in chat for clarification. Keep the stopped-result guard so stopping a task cannot itself restart the same request.

Please update both routing prompts and the manual consistently. The current authorization test checks that the rule’s text appears in the prompts, but doesn’t test how the classifier handles these examples. Add positive and negative examples covering the distinctions above, and provide a before/after classifier evaluation with the model and settings recorded. Preserve the regression showing that a stopped-result wake cannot respawn the task while a fresh human request remains eligible.

The goal is to prevent unauthorized work without suppressing ordinary ways users ask us to do things.