fix(bigtable): eliminate stats-handler MD race in internal/metrics tracer (#20158)

## Summary

- Hoists per-attempt cluster/zone/transport/server-latency extraction
out of `HandleRPC`'s `stats.End` branch and into a new `ingestMetadata`
helper that runs on the `InHeader`/`InTrailer` dispatches. `End` now
reads only already-parsed primitives — never the raw `metadata.MD` — so
the cross-goroutine race on the map is gone.
- Serializes the primitive-field writes vs reads with a per-`Tracer`
`sync.Mutex`. Only held around the field access, never across
`metric.Record` calls. `CreateTracer` now returns `*Tracer` so the
embedded mutex isn't copied out of the factory.
- Adds a deterministic `-race` regression test (`tracer_race_test.go`)
that reproduced the failing interleave on the pre-fix code and passes
cleanly on the fix.

## Race being fixed

Reported in the wild by the nightly integration suite; race dump
captured from `TestIntegration_Presidents`:

```
WARNING: DATA RACE
Read  at 0x…5ac8 by goroutine 5793 (csAttempt.finish → HandleRPC[*stats.End])
  bigtable/internal/metrics/tracer.go:867
Previous write at 0x…5ac8 by goroutine 1478 (http2Client.operateHeaders → HandleRPC[*stats.InTrailer])
  bigtable/internal/metrics/tracer.go:859
```

Two follow-on races on the same run against the underlying `metadata.MD`
map (`MD.Copy` in `operateHeaders` vs `MD.Get` in `extractLocation`).
All three came from the same design flaw: `HandleRPC` stored `ev.Header`
/ `ev.Trailer` on the current attempt from `InHeader` / `InTrailer`,
then re-read them under `stats.End`. gRPC's `stats.Handler` contract
does **not** promise `InHeader → InTrailer → End` dispatch on a single
goroutine — under cancel / deadline / GOAWAY, `csAttempt.finish`
(`google.golang.org/grpc@1.82.0/stream.go:1251`) fires `End` from the
caller goroutine while the transport reader (`http2_client.go:1650`) is
still processing the trailer frame.

Also plausibly implicated in the FlakyBot P1 burst against `30b1dfa0db`
on the same nightly (#20147, #20148, #20150, #20151, #20152), all of
which are TestIntegration_* failures with no attached stack — the Sponge
log is Google-internal, but the timing (all P1s stem from the same
invocation, and the metrics refactor #20099 that introduced this pattern
shipped six days earlier) strongly suggests the same underlying race.

## Design (why this exact fix)

Option A of the several considered — the alternatives were:

- **B: add a mutex around `metadata.MD.Get`** inside
`RecordAttemptCompletion`. Fixes the primitive-field race but not the
map-content race (gRPC's transport owns the map and mutates it inside
`operateHeaders`). Rejected.
- **C: plumb server headers/trailers through `stats.End`.** Requires a
gRPC-side change. Not viable short-term.

Option A eliminates cross-goroutine access to the MD entirely — the raw
map is read exactly once on the goroutine that received it, then
dropped. The mutex only guards the small set of already-parsed primitive
fields that `End` needs to read.

`extractLocation` / `extractPeerInfo` / `extractServerLatency` all check
header first then trailer, so passing one MD at a time (with the
`locationExtracted` / `peerInfoExtracted` booleans + the `serverLatency
== 0` gate) preserves the exact header-preferred-trailer-fallback
behaviour.

## Test plan

- [x] `go test -race -count=5 -run
TestHandleRPC_ConcurrentInTrailerAndEnd_NoRace -timeout=120s
./bigtable/internal/metrics/` — passes; same test tripped the race on
the pre-fix code.
- [x] `go test -race -count=1 -timeout=120s
./bigtable/internal/metrics/...` — full package suite passes under race.
- [x] `go vet ./...` clean.
- [x] `go build ./...` clean.
- [ ] Follow-up: rerun the nightly integration suite to close out the
sibling FlakyBot issues if the fix eliminates them.