End a task on the claim's success verdict, not the attacker's

[RoldSI]

The bug

The run loop breaks only on the optimizer's RunEndResponse(done=True):

done = isinstance(end_response, RunEndResponse) and end_response.done   # :1677
logger.info("... score=%.4f success=%s done=%s", ..., evaluation.success, done)
...
if done:            # :1507 — the only way the loop breaks
    stop_reason = "done"

evaluation.success is right there. It is computed, logged, and thrown away. The
framework will cheerfully log success=True done=False and launch another run.

This contradicts the project's own stated principle — the SecurityClaim decides
success, and attacker feedback is "for steering the next attempt, not for
self-certifying a win" — while termination is delegated entirely to the
attacker's self-report.

Why it has gone unnoticed

Almost every attacker/scope stops at the first win anyway, because the optimizer
is told it won (include_feedback=True) and sets done itself. The gap only
opens for a blind threat model with a multi-run budget, where the optimizer
cannot see the verdict and so cannot act on it.

Measured on a DecodingTrust-Agent sweep (16,390 tasks), every post-success run in
the whole campaign came from the one cell with that combination:

won tasks that kept running	52 of 52
further victim episodes	785
won on run 1, then ran ~19 more	31
one task scored 1.0 on	all 20 runs
recorded stop_reason	done 44, timeout 8

The record damage outlasts the wasted compute: a task that stopped because it
won is indistinguishable from one that exhausted its budget, and eight tasks that
had already succeeded are filed as timeouts. It also skews cross-scope
comparison — mean runs/task was 18.96 in the blind scope against 16.00 in the
sighted one, with attacker spend tracking it, so the blind scope reads as a more
persistent attacker as an artifact of not being told it had won.

The change

Controller(stop_on_success: bool = True) and a new "success" stop reason.

• Checked before reset_ephemeral_state(). There is no next run to reset
  for, and targets already document that reset is not called after the final run.
  For a container-backed target that reset is the most expensive step in the loop.
• When both would apply, "success" wins over "done". "done" is ambiguous —
  an attacker that gave up returns it too. "success" says the framework ended it
  on a win.
• Blindness is preserved. Ending the task leaks nothing: the optimizer is torn
  down and no evaluation is ever sent to it.
• stop_on_success=False restores the old loop exactly, which is what an
  attack-reliability study wants (how many of N attempts succeed, not whether
  any did).

The sharp edge

"success" had to be added to three separate completed-reason tuples —
_threat_model_end_event, the persistence summary, and the live reporter. Missing
any one of them drops every win out of both the ASR numerator and denominator and
reports a perfect sweep as 0/0. There is a regression test for exactly this
(test_a_win_still_counts_in_the_asr).

Behaviour change

Tasks that previously ran on after a win now stop at it, so run counts and stop
reasons are not comparable across this change. ASR is unaffected: success
latched before and latches now. Resume is unaffected: is_kept keys on the
derived status, which was already "success" whenever success=True.

Existing tests split cleanly, which is the change being made auditable:

• tests exercising loop mechanics (run counts, max_runs, budget) used a
  succeeding stub only incidentally → now use StubTask(success=False)
• tests whose premise is what happens after a win (success latching, feedback
  read on run 2, truncated-but-successful, attacker spend surviving a cancel) →
  pass stop_on_success=False explicitly, with a comment saying why

New tests

• a blind attacker that never says done stops at the win
• stop_on_success=False keeps running after a win
• "success" beats the optimizer's own done
• a won task skips the final reset_ephemeral_state()
• a win still counts in the ASR

Checks

594 passed (589 + 5 new) · mypy clean on 25 files · ruff check and
ruff format clean · docs updated in reference/controller.md and
reference/results.md, including an explicit behaviour-change note.