Allow trusted host init scripts to preserve direct-script review

首先，沿着内置 shell 工具的审批和直接脚本审查流程进行追踪，同时查看公开的按会话划分的 shell.initScripts API。比较 Bash 和 PowerShell 主机激活脚本的表示方式，然后确定如何将精确内容或信任元数据绑定到已审查的操作，同时不削弱对用户控制或不可读脚本的审查；当能够为明确受信任且可更新的主机脚本保留安全的直接脚本审查时，即视为完成。

Context

VS Code is adopting the public per-session shell.initScripts API so the SDK built-in shell tool can load the user's shell profile and activate the workspace-selected Python environment:

https://github.com/microsoft/vscode/pull/332593

Observed behavior

With no init scripts configured, a direct script invocation can be reviewed using the script and interpreter content under the normal permission flow.

When the same session has any host-provided shell.initScripts entry, the direct script invocation instead requires explicit approval because the shell environment can alter the script action.

This is secure as a conservative default, but it means an SDK consumer cannot opt into a known, host-generated activation script without changing approval behavior for otherwise identical direct script commands.

Ask

Please consider a public SDK contract for trusted host-provided init scripts that preserves safe direct-script review when possible.

Possible shapes include:

• allowing the SDK/runtime to incorporate the exact init-script content into the reviewed action/fingerprint; or
• adding explicit trust metadata for host-generated init scripts, with a conservative default for existing callers.

The behavior must remain secure when init scripts are user-controlled, mutable, unreadable, or otherwise cannot be bound to the reviewed action.

Consumer requirements

• Per-session and updateable, matching shell.initScripts.
• Applies to the built-in shell tool.
• Does not weaken approval for arbitrary or unbound startup scripts.
• Works for Bash and PowerShell host activation scripts.