fix(spanner): avoid data race on DIRECTPATH_CHANNEL_CREATED by using volatile

[rahul2393]

Fixes b/509632639.

Problem

GapicSpannerRpc declared a process-wide mutable static flag:

public static boolean DIRECTPATH_CHANNEL_CREATED = false;

The flag is written from the GapicSpannerRpc constructor without synchronization and read by HeaderInterceptor when populating the directpath_enabled built-in metrics attribute. When multiple Spanner clients are constructed concurrently (for example Apache Beam's DirectRunner initializing DoFns on multiple worker threads), the unsynchronized write/read pair is a data race; ThreadSanitizer halts the JVM on it.

Fix

Declare the field volatile:

public static volatile boolean DIRECTPATH_CHANNEL_CREATED = false;

• The volatile write in the constructor happens-before every subsequent volatile read in HeaderInterceptor, eliminating the data race. The flag has no read-modify-write usage, so volatile is sufficient; the existing last-writer-wins semantics are preserved unchanged.
• volatile was chosen over AtomicBoolean deliberately: it keeps the field's source and binary signature (boolean) intact, so any external code reading GapicSpannerRpc.DIRECTPATH_CHANNEL_CREATED keeps compiling and linking. (The class is @InternalApi and the spi.v1 package is excluded from clirr checks, but there is no reason to break the field's ABI when volatile fixes the race equally well.)
• Javadoc on the field documents the concurrency semantics.

[gemini-code-assist]

Code Review

This pull request addresses a potential data race during concurrent client construction by marking the static field DIRECTPATH_CHANNEL_CREATED as volatile in GapicSpannerRpc, and introduces a concurrent unit test to verify this fix. The review feedback recommends improving the test's cleanup block by adding a null check and awaiting the termination of the ExecutorService to prevent potential thread leaks and NullPointerExceptions.