fix(supervise): stop external drivers after accepted results

[drewstone]

Problem

An external supervisor could accept a result, return stop=true, and still continue its active harness.
The next provider turn could fail before Runtime materialized the accepted result.

Fix

• Notify Runtime once when submit_result accepts or stop declares completion.
• Abort the active external DriveHarness through a documented AbortSignal.
• Merge that signal into automatic bridge executor execution.
• Treat explicit coordination stop as terminal and preserve the accepted result.
• Cover accepted-submit plus redundant-stop one-shot behavior and provider-call prevention.

Proof

• Focused kernel tests: 69/69 passed.
• Lint: 585 files passed.
• Typecheck and example typecheck passed.
• docs:check and docs:freshness passed.
• Full suite: 2,597/2,604 passed, 6 skipped.
  The one failure is the pre-existing moving-Pi model identity test at tests/kernel/loop-dispatch.test.ts line 611.
  It is unrelated to this diff.

Raw K evidence showed submit_result returned accepted=true, retained=this-result, stop=true, followed by a redundant stop and four provider 429s.
Runtime then recorded unknown materialization.
This patch closes that missing cancellation path without weakening materialization checks.

[tangletools]

✅ Auto-approved drewstone PR — a8458489

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

This approval is provisional. It rests on the audit running. If the audit cannot run — for example the CLI bridge rejects it — this approval is dismissed rather than left standing, so an unrun check never reads as a passing one.

_{tangletools · auto-approval · reason: drewstone_author · 2026-08-13T21:28:27Z}