Extract built-in task handlers from TaskExecutor

[ianphil]

Goal

Move built-in runtime handlers out of TaskExecutor so Bash, PowerShell, one-shot Copilot prompt/agent, and shared Copilot agent sessions are all attached through the same handler-oriented model.

Context

TaskExecutor already has a clean dispatch model via register(TaskType, TaskHandler), but Bash and PowerShell are currently implemented as executor methods because they rely on executor-owned subprocess tracking, cancellation, timeout handling, and output events. The shared-session Copilot agent work adds another handler implementation and makes this split more visible.

Desired direction

• Keep Task as declarative task data.
• Keep TaskExecutor focused on lifecycle, retries, persistence, events, cancellation, and dispatch.
• Move built-in handlers into dedicated handler modules/classes.
• Preserve current default behavior for TaskExecutor().
• Continue supporting TaskExecutor.empty() plus explicit handler registration.
• Avoid making task factories carry runtime/session policy.

Open design questions

• What execution services should TaskContext expose to subprocess handlers?
• Should handlers be plain callables only, or optionally closeable/resource-owning objects?
• Should TaskExecutor.close() ever close registered handlers, or should resource ownership stay explicit?
• Where should public handler factories live: ttasks.handlers, ttasks.copilot, or both?

Not in scope

• Replacing existing default handlers immediately.
• Changing the public task factories.
• Requiring users to manually register default handlers.