SDK/host can now programmatically grant workspace trust via a new workspaceTrust option

What

• The SDK/CLI initialize request now accepts an optional workspaceTrust object ({accepted, directory}) so a host application (for example, Claude Desktop's Code tab over SSH/WSL) can attest that it already showed its own trust dialog for the working directory, instead of the CLI needing to show its own.
• A new handler validates that the directory is an absolute path, resolves to the same trust key as the session's working directory, and isn't a screened/untrusted network path, then records the directory as trusted the same way the interactive terminal dialog does, and re-applies project settings afterward. The outcome is reported via telemetry.
• The initialize response gains a workspace_trust_recorded boolean (marked internal) reporting whether the attestation was actually persisted as trust — it can be false for reasons like an obfuscated/untrusted path, a wrong key, a write failure, or a home-directory session-only trust.
• The same workspace_trust_recorded field is included in the system-init/hello JSON payload sent out, alongside existing fields like current_permission_mode and hooks_applied.

Why This lets a host that already handles its own trust UI (like Claude Desktop) skip showing a redundant trust prompt inside the CLI, while still letting the CLI confirm and record whether that trust was actually saved.