SSH远程Warpify时，不应用$SHELL来判断使用哪个shell

[Godsing]

Pre-submit Checks

• I have searched Zap issues and there are no duplicates.
• This bug is in Zap itself — not in upstream Zap's cloud account, billing, Warpify SSO, or cloud-only features.
• I have included relevant logs (RUST_LOG=info output, panic traces, etc.). Optional, but greatly speeds up triage.
• If the bug is in the AI / BYOP path, I have included the provider name, base URL pattern (redacted), and model id.

Describe the bug

SSH Warpify Shell 判断逻辑问题说明

问题现象

开启 Warpify，但未开启「使用Tmux Warpify」 时，SSH 远程登录后加载的 Shell 并非预期的 zsh，实际启动为 bash。

根因分析

翻阅 zap 仓库源码后确认判断逻辑：
未启用 Tmux 版 Warpify 时，程序仅依靠环境变量 $SHELL 判定要拉起的终端，不会读取系统底层配置如/etc/passwd 或 getent passwd 去获取默认 Shell

缺陷影响

若 $SHELL 环境变量因脚本、配置、第三方工具等场景被意外篡改，Warpify 会错误使用变量内记录的 Shell，和系统实际配置的默认登录 Shell 不一致，出现终端不符合预期的问题。

优化建议

SSH 远程 Warpify 场景下，放弃使用 $SHELL 环境变量作为判断依据，改用底层用户配置接口读取真实默认 Shell。

To reproduce

在远程机器的环境初始化相关文件中配置 export SHELL=非默认shell的路径，然后在开启 Warpify、但没开启「使用Tmux Warpify」的情况下进行 SSH 登录即可复现。

Expected behavior

No response

Screenshots, videos, and logs

No response

Operating system (OS)

macOS

Operating system and version

macos Tahoe Version 26.3.1 (a) (25D771280a)

Shell version

No response

Zap version / commit

v2026.07.01.1

AI / BYOP path involved?

No — non-AI bug (terminal, blocks, UI, shortcuts, etc.)

BYOP provider (if applicable)

No response

Regression

No, this issue has existed throughout my use of Zap.

Last known good build / date (if regression)

No response

Additional context

No response

Does this block your daily use of Zap?

Yes — this prevents me from using Zap daily.

Reproducible only in Zap?

Only in Zap.