fix(pubsub/v2): prevent nil span panic in Subscriber.Receive

[fredrikaverpil]

Why?

When tracing is enabled on a pubsub v2 subscriber, there is a race between the subscriber loop and the ack/nack/expiry paths. activeSpans is a sync.Map shared across goroutines, and the span can be deleted between the Store (message received in iter.receive) and the Load (message dispatched in Subscriber.Receive):

1. iter.receive() stores the subscribe span in activeSpans (iterator.go:382)
2. Before the subscriber loop reads it, one of these deletes the span concurrently:
   • Message expiry: keepAliveDeadlines cleanup calls activeSpans.LoadAndDelete (iterator.go:582)
   • Ack: sendAck calls activeSpans.LoadAndDelete (iterator.go:659)
   • Nack: sendModAck with isNack=true calls activeSpans.LoadAndDelete (iterator.go:739)
3. activeSpans.Load(ackh.ackID) returns ok=false, so ccSpan stays nil (subscriber.go:408)
4. ccSpan.End() panics on nil (subscriber.go:427)

What?

Add a nil check before calling ccSpan.End(). If the parent subscribe span was already removed from activeSpans, there is nothing to link the concurrency control span to — skipping it seems like the correct semantic behavior.

Notes

The issue reporter (@magnusewe) noted "this started happening after the client had been running for a while", which aligns with message expiry being the most likely trigger.

Fixes #14277

[gemini-code-assist]

Code Review

This pull request adds a null check for ccSpan in the Receive method of the subscriber. The review feedback suggests simplifying the conditional check by removing the redundant iter.enableTracing flag, as the null check for ccSpan is sufficient.