Support awaited cleanup before agent-created worktrees are removed

Agent-created worktrees support setup tasks through:

```json
"runOptions": {
"runOn": "worktreeCreated"
}
```

This makes it possible to provision resources for an isolated agent session, such as:

- A cloned development database
- A worktree-specific environment file and secrets
- A container, service, or allocated port
- Other temporary external resources

However, there is no corresponding supported lifecycle for cleaning up those resources when VS Code removes the worktree.

## Current behavior

1. Configure a `worktreeCreated` task that provisions an external resource.
2. Start an agent session using worktree isolation.
3. Mark the session as Done/archive it.
4. VS Code removes the worktree internally.
5. No workspace task, agent hook, or extension API is invoked and awaited before that removal.

`Stop` hooks are not suitable because they run when an individual agent execution stops. `SessionEnd` is also not equivalent because Mark as Done is an archive operation and does not dispose the session.

Filesystem watchers can detect removal after the fact, but they are not awaited, can miss events while the extension host is unavailable, and cannot reliably access worktree-local cleanup metadata after the directory has gone.

## Requested behavior

Please expose an awaited lifecycle before VS Code removes an agent-created worktree.

A task-based form symmetrical with `worktreeCreated` could look like:

```json
{
"label": "Clean up agent worktree",
"type": "shell",
"command": "pnpm",
"args": ["cleanup:agent-worktree"],
"runOptions": {
"runOn": "worktreeRemoving"
}
}
```

The cleanup task should:

- Run while the worktree still exists, with the worktree as its working directory.
- Be awaited before worktree removal continues.
- Run for both Mark as Done/archive and permanent session deletion.
- Receive the removal reason and stable session/worktree identity when practical.
- Surface failures instead of silently removing the worktree before cleanup completes. A bounded timeout and an explicit "remove anyway" path would avoid indefinite blocking.

An awaited extension API such as `workspace.onWillRemoveAgentWorktree`, with an event `waitUntil(...)` mechanism, would provide the same underlying capability.

This would let workspace tooling manage the lifecycle of resources provisioned for isolated agent sessions. A separate reconciliation mechanism would still be needed for crashes or forced termination, but normal VS Code-initiated cleanup could be deterministic.

## Environment

- VS Code: 1.132.0
- Commit: df53daabb18cd157bdb08c7f01c34df936cf12f4c
- OS: Windows x64

Start by tracing the existing worktreeCreated task lifecycle and the paths for Mark as Done/archive and permanent session deletion. Compare those paths with extension lifecycle APIs and verify that cleanup runs in the worktree, is awaited, receives the requested context, and exposes failure or a remove-anyway path before removal proceeds.

Written by the indexing model from the issue text.