fix(bigtable): sessionTableHandle self-heals across cache eviction - #20296

Addresses the round-2 reviews on 82cd0a3 across three reviewers.

Iterative dispatch() helper (thermo + igor blockers). ReadRow /
MutateRow are shape-twins; both used to duplicate the self-heal
conditional (drifting at comment level already, would drift at logic
level as future methods land). Extract dispatch() on *sessionTableHandle
that returns the live handle via a for-loop (not recursion — igor's
catch: a hair-trigger TTL test could otherwise recurse if the fresh
successor gets evicted mid-flight). ReadRow / MutateRow collapse to
3-line pass-throughs: dispatch → touch → api.op. Any future proxied
method drops in as a 3-liner with zero branch structure to keep in
sync. Bonus: touch fires on the live handle, not the doomed original.

Rename reopenAfterEviction → resolveSuccessor (igor). "Reopen" reads
as "revive h in place"; we're actually asking the cache for whoever's
live under h.key now — could be a peer's winner, could be a fresh
one we just minted. New name is honest about what happens.

Kill dead fresh==h guard (sushanb + thermo). After removeEntry(h),
getOrOpen can't return h (hit branch requires entries[key]==h, slow
path mints a fresh *sessionTableHandle). The !ok half of the type
assertion stays as a defensive check but the fresh==h half is
provably unreachable.

Close-ordering doc reworded (all three reviewers). "Nanoseconds"
window claim was wrong — a reader preempted between Load(false) and
api.dispatch can span arbitrary wall-clock under scheduler pressure.
Rewrite to the honest three-step invariant: (1) evicted.Store(true)
routes future readers through self-heal, (2) removeEntry drops from
the map, (3) api.Close tears down. (1)→(3) is the load-bearing
ordering; (2) tightens the window. Also documents which readers the
flag actually helps (post-Load-true only, not in-flight pre-Load).

WHY on openFn field (sushanb + igor). Documents the set-once
*Client.sessionImpl invariant (if that ever becomes reconfigurable,
self-heal will stale) AND the "invoked only via getOrOpen which
nil-guards on close" invariant (direct openFn calls would lose the
guard).

Fix EvictedReopenFailsGracefully (all three). Was Logf-not-assert;
docstring claimed to test a deadApi that wasn't wired. Rewritten:
wrap ReadRow in context.WithTimeout(1s) for hang detection; assert
cache.entries stays empty after the call (the closed-cache guard
inside getOrOpen must have refused to install the freshly-opened
api, releasing it — otherwise we'd leak).

Three new tests (sushanb):
 - TestSessionTableHandle_SweeperEvictionSelfHeals — the actual
   production trigger. Prior tests used explicit handle.Close; this
   drives sweepOnce after TTL and asserts the held pointer still
   works.
 - TestSessionTableHandle_ConcurrentEvictAndReadRace — -race stress:
   evictor spins Close+reopen while reader spins ReadRow through the
   original held handle.
 - TestSessionTableHandle_EvictionStormConvergesOnSingleInstalled —
   N=32 concurrent post-eviction RPCs. Pins the real invariant
   getOrOpen guarantees (exactly one installed successor + every
   loser api closed), not the aspirational single-flight-openFn one
   my first draft assumed. Making openFn genuinely single-flight
   would be a real perf win but is out of scope for this fix.

Split test file (thermo blocker). open_test.go crossed 1006 lines
after the new tests landed. All cache-focused tests + helpers +
fakes (fakeClock, newTestSessionTableCache, openNoop, openClosing,
closeCountingTable, all TestSessionTableCache_* and
TestSessionTableHandle_*) move to a new session_table_cache_test.go
(597 lines). open_test.go drops to 629. Both under threshold.

SPEC trim (sushanb + igor). Trimmed the TableShim bullet from a
paragraph to an invariant + Java-parity note ("Go-specific hazard
— Java's session-table cache has no TTL sweeper, so Design C has
no direct Java analog").

Non-blockers deferred:
 - Single-flight openFn in getOrOpen (would save N-1 pool creations
   in an eviction storm; separate perf follow-up).
 - Narrowing getOrOpen's return to *sessionTableHandle (thermo nit;
   touches the interface at the public boundary — separate PR).

Adopts gemini-code-assist's PR googleapis#20296 review suggestion (with
modifications approved by igor round-2):

Add `successor atomic.Pointer[sessionTableHandle]` to sessionTableHandle
and use it in dispatch() to cache the resolved live successor. Without
this, EVERY RPC on a stale handle pays 2× cache.mu (removeEntry +
getOrOpen) forever, because TableShim's cached pointer never gets
re-fetched. With it, only the FIRST post-eviction RPC pays that cost;
subsequent ones are one extra atomic.Load.

dispatch() also applies path compression on return so a chain of
evicted handles collapses on the next observation — union-find with
path compression, standard technique. Intermediate handles become
unreachable from h and are eligible for GC.

Store races are documented on the field and safe by construction:
  - Two concurrent dispatches on the same evicted handle race into
    getOrOpen, which is at-most-one-per-key (loser closes its local
    api and returns the winner's handle), so both racers see the
    same `next` — the Store is idempotent.
  - Divergent-`next` race (successor itself evicted between one
    dispatch's resolveSuccessor and another's Store) writes a stale
    pointer; the next dispatch's outer for loop walks one extra hop
    through it and updates. No correctness bug, just a lagging
    compression.

Preserves the existing dispatch() doc block (eviction branch + loop
rationale + cache-closed fallthrough) and adds the path-compression
paragraph.

Modifications from gemini's original suggestion:
  - Typo: sucessor → successor.
  - Single Store site inside the loop (gemini had two writes:
    per-iteration and at the return). One is enough — the
    per-iteration Store handles the fresh-resolve case; the terminal
    h.successor.Store(cur) covers the "we walked a chain" case.
  - Preserved the fallthrough-to-cur-on-nil semantic + comment.

No new tests — TestSessionTableHandle_EvictionStormConvergesOnSingleInstalled
already exercises N=32 concurrent post-eviction dispatch calls under
-race, which is where the successor-cache races would show up.