fix(goctl): resolve pb imports across sibling modules (#5511)

[Meng-Xin]

Summary

Fix goctl rpc protoc import generation when --go_out / --go-grpc_out point to a sibling Go module instead of the current module.

Previously, goctl derived the generated pb import path by joining the current project module path with the pb output directory on disk. On Windows, when the pb output directory lived outside the current module, this could produce invalid imports such as:

"sales-admin/F:/coding/learn/zero-rpc/sales-center/pb/admin"

[Meng-Xin]

This PR fixes the import-path resolution in `goctl` itself when pb output is generated into a sibling Go module. It is intended to support the multi-module `go.work` layout directly, rather than only relying on changing `go_package` as a workaround.

[kevwan]

Review

This PR fixes a real pain point in multi-module Go workspaces on Windows (#5511).

Problem: When running goctl rpc protoc from one module (sales-admin) with --go_out pointing to a sibling module's directory, goctl incorrectly prepends the current module name to the absolute path of the output directory, producing imports like:

import "sales-admin/F:/coding/learn/zero-rpc/sales-center/gen/admin"  // ❌

instead of the correct:

import "sales-center/gen/admin"  // ✅

The fix: When the pb output directory belongs to a different Go module (detected by finding a go.mod in a parent of the output path), use that module's name as the import prefix instead of the current module's name.

Code review points to verify:

1. Does the fix correctly traverse parent directories to find go.mod? Check for proper handling of the root directory boundary.
2. Does the path separator handling work correctly on both Windows (\) and Unix (/)? This is especially important since the bug was reported on Windows.
3. Are there tests that run on both platforms, or at least test the path normalization logic independently?
4. What happens when the go.mod in the output directory doesn't exist (e.g., module not yet initialized)? The fix should fall back gracefully to the previous behavior.

Overall: The approach is correct. Please ensure the cross-platform path handling is covered by tests before merging.