Add cancellable SDK run controller

[victorxheng]

User request

A Freebuff cloud user reported that long-running terminal commands or autonomous agent work can get stuck for 20+ minutes, and requested a user-controlled way to terminate the running work.

Implementation

• Added CodebuffRunController and createRunController() in the SDK.
• Added CodebuffClient.runCancellable(), which returns { id, controller, signal, result, cancel } for hosts to keep in an in-flight run registry and call from a Stop/Terminate UI or API action.
• The cancel path composes with any caller-provided AbortSignal, then flows through the existing runtime cancellation path used by LLM streams, subagents, tool execution, and terminal commands.
• Exported the new controller and CancellableRun type from the SDK entrypoint.
• Added tests proving cancel() aborts an already-running agent signal and that external caller signals still abort the same run.

Confidence / verification

Ready to merge with high confidence for the SDK/runtime control surface. Verified locally:

• bun test sdk/src/__tests__/client-cancellable-run.test.ts sdk/src/__tests__/run-cancellation.test.ts
• cd sdk && bun run typecheck
• cd sdk && bun run build

Note: this public snapshot does not include the tracked cloud web route/component code for the Stop button itself; this PR provides the production SDK primitive that the cloud host can wire to its stop endpoint/UI without bypassing existing runtime cancellation semantics.

This is a clean, focused addition to sdk/src/run-controller.ts. A few positives:

• CodebuffRunController and createRunController() are small, single-purpose primitives that compose naturally with existing AbortSignal-based cancellation already used for LLM streams/subagents/terminal commands (per client.ts's run({ ...options, signal })), rather than introducing a parallel cancellation mechanism.
• anySignal() correctly handles the 0/1/N signal cases and falls back to manual event listeners when AbortSignal.any isn't available - good defensive coding for older runtimes.
• The tests in client-cancellable-run.test.ts are solid: one verifies controller.cancel() propagates through to the runtime's signal, the other verifies an externally-supplied signal still aborts the same run and that the controller itself remains uncancelled in that case. Both assert on the resulting RunState.output shape, which matches how this repo already tests cancellation elsewhere.
• Public API surface (CodebuffClient.runCancellable, exports from index.ts) is minimal and additive - no existing behavior changes.

A couple of things worth double-checking before porting:

• cancel()'s default reason wraps a string into new Error(reason) - worth confirming downstream consumers (UI, logging) expect an Error here rather than a raw string, since the existing run() signal-abort path may format reasons differently.
• No changes to SDK docs/README describing the new runCancellable entrypoint - minor, but worth adding given this is a public API addition.

Overall this looks like a real, well-scoped fix for the reported 20+ minute stuck-run problem, and the test coverage gives confidence it behaves correctly under both self-initiated and caller-initiated cancellation.

Apologies — this PR was auto-closed by GitHub when we force-pushed a history rewrite of this repository (repository maintenance; every commit SHA changed). That was not a judgment on this PR, and GitHub does not allow us to reopen it because the commits it was based on no longer exist in the new history.

If you'd like to continue with this change: rebase your branch onto the new main (or recreate it from a fresh clone) and open a new PR — feel free to link back to this one for context, and we'll pick up the review there.

Sorry for the churn, and thanks for contributing.