edit, provider: stop inline comments leaking into dotenv values - #439

Friendly ping when you have a moment. CI is green and this applies cleanly on current main. Happy to adjust anything.

谢谢修复！edit.GetEnvFile 的行为和 dotenv 一致，写入后读回也都对，两个测试在修复前确实会失败。还有一处：internal/provider/google.go 的 envFileValue 对「带引号的值后面跟注释」仍然读错，比如 GOOGLE_CLOUD_PROJECT="my-proj" # work 会原样返回 "my-proj" # work，K='a#b' # c 会得到 a#b' # c。provider 包已经引用了 edit，建议直接让 envFileValue 调用 edit.GetEnvFile，两处共用一套解析，再给 google 的测试加上这个用例。改好后我们再拉下来验证合并～

Thanks, agreed. Pushed 50201cd: envFileValue in internal/provider/google.go now calls edit.GetEnvFile, so both readers share one parser. Added Google regression cases for a double-quoted value followed by a comment (GOOGLE_CLOUD_PROJECT="my-proj" # work) and a single-quoted value containing # followed by a comment (K='a#b' # c). Both fail on the previous head and pass now. internal/edit and the Google/env provider tests pass; I have not run the whole internal/provider suite to green.

Thanks for the update — verified 50201cd on current main: envFileValue now shares edit.GetEnvFile, the quoted+comment cases read right, and the new tests fail before / pass after. I also compared GetEnvFile with Gemini CLI's own dotenv parser (0.62) over a set of comment/quote lines and they now agree, and in a sandbox a route-to-magpie-and-back no longer bakes # my key into GEMINI_API_KEY. Full test chain passes. Merging.