Observe VS Code trusted folders in Copilot

Copilot should know which folders are trusted in VS Code, and also ask VS Code if it need trust to a new folder.

https://github.com/microsoft/vscode/issues/332700 shows the scenario where Copilot should delegate the 'trust folder' request to VS Code.

### What VS Code can do today

When creating an SDK session, VS Code can pass:

```ts
{
workingDirectory: workspaceFolder,
trustWorkingDirectory: "session"
}
```

The `trustWorkingDirectory` contract supports:

- **`"session"`** — host-attested trust for this session only; nothing is written to disk.
- **`"user"`** — persists the directory into Copilot’s own `trustedFolders` configuration.

This is defined in `ProtocolSessionCreateRequest` and exposed in the generated TypeScript contract at `runtime-contracts.ts`.

The trust declaration:

- Requires an explicit, absolute `workingDirectory`.
- Is rejected for RPC-backed filesystems.
- Makes workspace-local MCP configuration, hooks, agents, skills, and other workspace plugins eligible for discovery.
- Does not itself enable ambient discovery; `enableConfigDiscovery` still controls that.
- Is revoked if the session moves to a different working directory.

For VS Code, **`"session"` is the appropriate mapping from VS Code Workspace Trust**, because VS Code remains the authority and the SDK does not maintain a second persistent trust decision.

### Can VS Code provide a set of trusted folders?

**Not as a host-attested set.** There is currently no `trustedFolders: string[]` session-create option.

There are experimental APIs for individual folders:

```ts
await session.permissions.folderTrust.isTrusted({ path });
await session.permissions.folderTrust.addTrusted({ path });
```

They are declared in `rpc.rs` and surfaced in `apiInterfaces.ts`.

However, `addTrusted` writes to Copilot’s persistent `trustedFolders` configuration, as implemented in `permissions.rs`. Calling it for every VS Code trusted folder would duplicate VS Code’s trust database and potentially outlive VS Code’s trust decision. It is therefore not a good substitute for a session-scoped trusted-folder set.

### Can the SDK tell VS Code that trust is needed?

**No dedicated notification or event exists today.**

The SDK event contract has:

- General tool permission requests such as `permission.requested`.
- Host events for auth, extensions, MCP, logging, and similar operations.

But it has no `workspaceTrustRequested`, `folderTrustRequired`, or equivalent event. Folder trust is currently an **up-front host declaration**: an embedded host is expected to know its own trust state when calling `session.create`.

If trust is absent, the runtime generally fails closed by excluding workspace-local configuration; it does not pause and ask the host to obtain trust. The `folderTrust.isTrusted` API is a host-initiated query against Copilot’s persisted trust state, not a runtime-to-host request.

## Bottom line

| Capability | State |
|---|---|
| VS Code attests trust for the session working directory | **Supported** via `trustWorkingDirectory: "session"` |
| VS Code permanently trusts the working directory in Copilot config | **Supported** via `"user"`, but usually undesirable for VS Code |
| VS Code passes all its trusted workspace folders as a set | **Not supported** |
| SDK asks VS Code to obtain workspace trust | **Not supported** |
| Host checks/adds individual folders in Copilot’s persisted trust store | **Supported**, experimental |

So the single-root VS Code scenario is supported. Complete multi-root integration and runtime-initiated trust escalation still need contract work—likely a session-scoped host trust snapshot/set plus a typed “trust required” event.