Use relative imports for same-package pb2 modules

[LysanderGG]

Summary

• When a generated twirp file imports a _pb2 module from the same package directory, emit a relative import (from . import v1_pb2) instead of an absolute one (from crypto import v1_pb2)
• Cross-package imports (e.g. google.protobuf) remain absolute
• Fixes ModuleNotFoundError when generated files are nested under a different top-level package (e.g. bridge.proto.crypto.v1_twirp trying from crypto import v1_pb2)

Context

In the marketdata-pipeline bridge, protos are at crypto/v1.proto (relative to --proto_path) but the generated Python files live under bridge/proto/crypto/. The absolute import from crypto import v1_pb2 fails because crypto is not a top-level Python package.

Changes

• import_builder.go: track current file's directory, emit . when import path matches
• generator.go: pass current filename to newImportBuilder
• generator_test.go: updated tests covering same-package (relative) and cross-package (absolute) cases

Test plan

• Go unit tests pass
• Built plugin and regenerated marketdata-pipeline bridge proto files
• Verified all same-package imports use from . import
• Verified cross-package imports (google.protobuf) stay absolute
• Bridge starts and serves healthcheck with the new generated code

🤖 Generated with Claude Code

[LysanderGG]

This is a plugin-only change — no runtime modification needed. After merging, a new protoc-gen-twirpy release tag (e.g. protoc-gen-twirpy/0.3.0-dev.2) should be created to publish the updated binary via goreleaser.