fix(bigtable): AFE picker latency signal — subtract poolWait and compute TransportLatency = wire − backend at source - #20281

SessionPoolImpl.Invoke fed the full user-visible latency (poolWait +
wire + backend) into noteVRpcOutcome, which routes to
sessionList.RecordVRpcOutcome and updates the per-AFE e2eEwma and
transportEwma. The AFE picker's cost signal was contaminated by
pool-side queue contention that the AFE itself had nothing to do
with.

Concrete impact observed in the sushanb-uc1 sandbox:

  Slow vRPC:  Latency=13.947ms  PoolWait=12.57ms  Transport=1.366ms
              Backend=431µs

  AFE 222545b8...  wire+AFE actual = 935µs
                   e2eEwma got fed 13.947ms  ← 15× overcharge

Under sustained saturation, every AFE picked during a queue spike
gets a 10-30ms sample fed into its EWMA. LeastLatencyPicker then
steers traffic AWAY from those AFEs on the next tick, and over time
every AFE's EWMA drifts upward as saturation events poison the
signal — the picker becomes a noise mirror instead of a routing
oracle.

Fix: compute rpcLatency = latency − poolWait inside the deferred
noteVRpcOutcome call and pass it instead of raw latency. Sessionz's
TotalLatency histogram is unaffected (still records the raw
user-visible latency at session_pool.go:552 — that's the correct
metric for user-visible p95/p99).

Defensive: clamp rpcLatency to 0 on the (theoretically unreachable)
edge where poolWait > latency, so a clock-skew glitch can't feed a
negative sample into PeakEwma.

No signature change to noteVRpcOutcome or RecordVRpcOutcome —
caller-side one-line fix.

…y; add computed TransportLatency

The old field name lied vs its doc comment. The value set at
session_vrpc.go:260 was time.Since(SentAt) — Send→Recv wall time
INCLUDING server backend. The doc claimed it was
"AttemptLatency - BackendLatency" (the AFE-attributable portion,
which subtracts backend). Two different quantities under one name;
downstream consumers (sessionz Transport histogram, OTel
transport_latencies, per-AFE picker) were all reading the wire-with-
backend value while thinking it was pure wire+AFE.

Split into two fields that match their names:

- WireLatency: client-measured Send→Recv wall time. Includes
  BackendLatency. Populated at source in Session.processResult.
- TransportLatency: WireLatency − BackendLatency. Populated in
  SessionPoolImpl.Invoke after BackendLatency is known. This is
  what the sessionz Transport histogram, OTel transport_latencies,
  and any AFE picker cost signal should consume.

wire ≥ backend by construction (wire = RTT + backend + decode) so
subtraction is unconditional; the existing `> 0` guard at the
histogram/OTel record sites catches the vanishingly-rare clock-skew
edge.

Together with the prior commit on this branch (feed rpcLatency =
latency − poolWait into RecordVRpcOutcome), the AFE picker now sees:
  e2eEwma        ← rpcLatency  (RPC-only, no pool contention)
  transportEwma  ← rpcLatency − backend  (wire + AFE, no server time)
which is what the picker's cost model has always assumed but the
inputs never actually delivered.

- invoke_result.go: one-liner doc "TransportLatency = WireLatency − BackendLatency".
- session_pool.go: one-liner "noteVRpcOutcome feeds e2e latency (not including CheckoutSession)"; inline `latency-poolWait` in the defer, drop the defensive < 0 clamp.
- session_vrpc.go: drop the local-var doc and the wire-≥-backend rationale.

No behavior change.