fix: return codes.Internal on recovered panic instead of nil error

[janwytze]

Problem

When Repanic is disabled (the default), recoverWithSentry recovers a handler panic and reports it to Sentry, but the server interceptors use unnamed return values, so after recovery the function falls through to its zero value — a nil error. gRPC then treats the RPC as successful:

• Streaming handlers return OK with a missing/partial response (silent data loss; metrics count it as success).
• Unary handlers return a nil response that fails to marshal, surfacing as an opaque Internal error that masks the real panic.

In all cases nothing distinguishes a panicked RPC from a healthy one at the gRPC layer.

Fix

• Give UnaryServerInterceptor and StreamServerInterceptor named returns.
• Have recoverWithSentry translate a recovered panic into status.Errorf(codes.Internal, "%v", err) (and mark the transaction SpanStatusInternalError) on the non-repanic path.
• Repanic: true behaviour is unchanged; normal handler errors pass through unchanged.

Tests

Adds tests that actually invoke the interceptors (the existing tests only cover construction):

• panic → recovered as codes.Internal (unary + stream)
• WithRepanicOption(true) → panic propagates (unary + stream)
• normal error passes through unchanged (unary + stream)

go build, go vet, gofmt, and go test ./... all pass.