[Bug]: Background task cancellation lacks execution-stop acknowledgement

## Summary

`TaskRepository.cancelTask(...)` records cancellation intent/terminal task state but provides no authoritative acknowledgement that the running local or remote child execution has actually stopped.

A caller can receive `true` and observe `TaskStatus.CANCELLED` while the child supplier is still executing.

## Reproduction

Using AgentScope Java main at `e3a412ed2cc944e401da861c8d5e464b967724e9` / `2.0.1-SNAPSHOT`:

1. Submit a local background subagent task whose supplier enters a running section and exposes latches before it returns.
2. Wait until the supplier is running.
3. Call `WorkspaceTaskRepository.cancelTask(rc, parentSessionId, taskId)`.
4. Observe `true` and a persisted `TaskRecord` with `CANCELLED`.
5. Release/observe the supplier.

Actual behavior: the supplier can continue after the repository reports cancellation. There is no typed cooperative/forced termination result to distinguish "cancellation recorded" from "execution stopped".

## Source evidence

`TaskRepository.cancelTask(...)` returns only a boolean documented as "task was found and cancellation was attempted".

For local tasks, `WorkspaceTaskRepository.cancelTask(...)` calls `local.cancel(true)`, then persists `cancelRequested=true` and `TaskStatus.CANCELLED`.

For remote tasks, the protocol cancellation exception is logged as a warning, but the repository still persists/returns cancellation success. Later persistence explicitly prevents a still-running thread from overwriting the terminal CANCELLED record.

These are reasonable repository-state semantics, but they are not an execution-stop acknowledgement.

## Expected behavior

Expose an AgentScope-owned typed cancellation/termination contract for background subagent executions, for example:

- cancellation request accepted/rejected;
- cooperative stop confirmed, forced stop confirmed, detached, timed out, or stop unavailable;
- local/remote execution identity and child session/task identity;
- idempotent repeated cancellation;
- a completion signal/event that parent close/cleanup can await with a caller-provided bound;
- remote protocol failure propagated as an authoritative stop result, not only a warning.

The exact API may differ, but product hosts must be able to distinguish `TaskRecord=CANCELLED` from "child execution has stopped" without maintaining their own executor handles or polling registry.

## Impact

Parent exit, workspace cleanup, and multi-child cancellation cannot safely proceed from task status alone. Treating CANCELLED as stopped risks detaching/cleaning a workspace while child execution is still active; adding a host-side executor/stop registry would duplicate Harness task ownership.