fix(env): detect Git Bash login shell profile on Windows

[akshar27]

Summary

detectShellProfile() always fell back to .bashrc on Windows, since SHELL (a POSIX convention) is never set there. But Git Bash's default launch is a login shell, which reads .bash_profile / .bash_login / .profile — never .bashrc. The injected env block gets written, the file looks correct, and the variables are never loaded. Scoped to win32 only; the existing macOS/Linux behavior is untouched.

Type of Change

• Bug fix (non-breaking change that fixes an issue)

Test Plan

• npx tsc --noEmit passes
• npx vitest run passes — 264 files, 3622 tests, including 7 new cases for this change
• Added/updated tests for the change

Real, end-to-end verification (not only unit tests), per the repo's testing rule:

I don't have a Windows machine, so I couldn't run the literal Git Bash repro from the issue. Instead I did the next most honest thing: npx tsc compiled the real source to plain JS (not the tsup CLI bundle, which has no importable exports), then ran a standalone Node script against that actual compiled artifact — real module resolution, real fs.existsSync calls, real EnvHandler class, with process.platform and a real temp $HOME swapped in (not mocked at the vitest level):

=== Reproducing the exact reported bug (#682) ===
PASS  Windows, no existing dotfiles → creates .bash_profile (matches nvm-windows/Git-Bash convention)
PASS  Windows, only .bashrc exists → does NOT return .bashrc (the reported bug)
PASS  Windows, .bash_profile exists → uses it

=== Confirming zero regression on the existing (non-Windows) path ===
PASS  macOS/Linux, SHELL unset → unchanged, still .bashrc
PASS  zsh path is untouched by this change

ALL CHECKS PASSED

.bash_login and .profile fallback (the two other cases) are covered by the added Vitest cases, which also use real fs/temp-dir operations, not mocks of the function under test.

Related Issues

Fixes #682

Notes for Reviewers

• Filed separately at @jeff-r2026's request in [bug] Windows: env 注入到 shell profile 时写的是原生路径，source 静默失败而 doctor 仍报通过 #661.
• src/uninstall.ts has an identical, unfixed copy of this same detectShellProfile() logic (not a call to the one in env.ts). Left out of this PR since detectShellProfile() falls back to ~/.bashrc on Windows, where the login shell never reads it #682 scoped the fix to env.ts specifically, and the two files' logic isn't shared — but flagging it explicitly: a Windows uninstall would still look in .bashrc to remove the block this PR now writes to .bash_profile/.bash_login/.profile, silently leaving it behind. Worth a follow-up (either a mirrored fix or extracting the shared helper the env.ts docstring already gestures at: "a second spelling of this choice would... report a correct install as broken" — the same risk now applies between env.ts and uninstall.ts).

[github-actions]

• [P1 blocking] Keep uninstall aligned with the new profile selection — src/resources/env.ts:358. Installation now writes to .bash_profile, .bash_login, or .profile on Windows, while src/uninstall.ts still checks only .bashrc. Consequently, teamai uninstall silently leaves the managed env block active. Update both paths or share the detection helper.
• [P1 blocking] Provide the required real-CLI E2E record — PR description, Test Plan. The standalone script imports a TypeScript-compiled module; it does not run the built teamai CLI. The trusted rules require npm run build followed by real-CLI end-to-end verification, so the current description lacks the mandatory E2E record.
• [P2 non-blocking] Restore stubbed environment variables — src/__tests__/env-handler.test.ts:240. vi.restoreAllMocks() does not undo vi.stubEnv(), leaving SHELL='' for subsequent tests. Add vi.unstubAllEnvs() to avoid order-dependent test pollution.

[jeff-r2026]

Please resolve the conflicts