Fix the run-breaking tool-result order; e2e test runs the slice (M2.1, PR D)

The first live run of the new loop's e2e test found that a fact recorded
while start_milestone was in flight landed between the tool call and its
result; both API formats reject that, so every later request in the run
failed. Views now keep each result right after its call. Scripted test
models check the APIs' ordering rules, so this can't pass unit tests
again.

The e2e tests no longer depend on the sandbox's history: each run asks for
a uniquely named function and works against a base branch of its own,
deleted afterwards. The review step asks for a change that can't already
be there. The scripted operator gives up after five fruitless answers, and
each run keeps its state store for inspection. The driver's prompt says
review fixes stay in the current milestone.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPQ14L3LikyefCMFBqEbKE

nisse-dev/src/nisse_dev/loop/agent.py

@@ -70,8 +70,8 @@ After the go-ahead, work in a milestone: call start_milestone before
 changing anything (never create or switch branches yourself), make the
 change, run the project's tests, then call finish_milestone with a summary.
 The harness commits, pushes and opens a PR, and you wait for review. Review
-comments arrive as messages: make the changes, run the tests, and call
-finish_milestone again to push the fix. When the PR has merged, call
+comments arrive as messages: make the changes within the same milestone (don't
+start another), run the tests, and call finish_milestone again to push the fix. When the PR has merged, call
 close_item with what was done, what was verified, and what is left open. If
 the PR is closed without merging, ask the operator what next.