## Summary
- Track goroutines spawned by `ConnectCore`/`ConnectSentries` with a
`WaitGroup`; `TxPool.Run` defers `Wait()` so it blocks until they all
exit
- Replace bare `time.Sleep` calls in retry loops with `select` on
`ctx.Done()` so goroutines exit promptly on cancellation instead of
sleeping through a 3-second backoff

These goroutines were previously fire-and-forget: after context
cancellation, `Run()` would return via the errgroup while the fetch
goroutines were still in retry sleeps or blocking on streams. Downstream
cleanup (`DB.Close()`, etc.) could then race with them.

Found while investigating flaky
`TestCaplinBlockProductionWithWithdrawalRequest` in #19981.

## Test plan
- [x] `go test -race ./txnprovider/txpool/` passes
- [x] `go test -race -count=3 ./cl/beacon/handler/ -run
TestCaplinBlockProductionWithWithdrawalRequest` passes without goroutine
leak

🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: info@weblogix.biz <admin@10gbps.weblogix.it>

…mit (erigontech#21444)

## Summary

`ExecModule.UpdateForkChoice` spawns the forkchoice work in a goroutine
and waited on a `done` channel that closes only after that goroutine
**fully returns** — i.e. after flush + commit + prune. For a
merge-extending fork at tip the forkchoice result is already sent on
`outcomeCh` *before* the commit (`ParallelStateFlushing` is on by
default), so the `<-done` wait threw that early-send away and blocked
the consensus client for the entire EL commit.

This removes the `<-done` wait: `UpdateForkChoice` returns as soon as
the result lands on `outcomeCh`.

## Live-tip A/B (this branch vs main)

Probe at the `ExecutionClientDirect.ForkChoiceUpdate` boundary (what
Caplin's clstages loop blocks on), live mainnet tip, same
datadir/machine/instrumentation:

| FCU-response wall (ms) | n | min | p50 | p90 | max | mean |
|------------------------|--:|----:|----:|----:|----:|-----:|
| **main** | 100 | 96.7 | **260.2** | 386.3 | 12160.8 | 390.1 |
| **this branch** | 82 | 0.7 | **1.2** | 3.0 | 4.3 | 1.7 |

~217× lower p50; distributions don't overlap (branch max 4.3 ms ≪ main
min 96.7 ms). This matches release/3.4's ~1.4 ms at the same boundary.
The `Timings: Forkchoice commit=…ms` line is unchanged — the commit
still costs the same, it just no longer blocks the consensus loop.
safe/finalized cadence is identical between branch and main, and wall
does not correlate with safe/finalized changes, so this is not about
forkchoice args.

Both A/B binaries are post-erigontech#21327, so the comparison isolates only the
`<-done` change — the gap is not confounded by the erigontech#21008/erigontech#20035
regression (both sides already have its fix).

## Scope / relationship to erigontech#21008

This is an **independent FCU-response-latency improvement**, not the fix
for the erigontech#21008 in-sync regression. The bisection attributes erigontech#21008 to
erigontech#20035, which is entirely CL-side (`cl/phase1/forkchoice/*`) and touches
no `execution/execmodule/` code — its `getFilterBlockTree`
spec-deviation regressed `GetHead` at epoch boundaries and is itself
already fixed on main by erigontech#21310/erigontech#21327. The `<-done` wait predates the
bisection's good commit `19f44b15cd` (it was added in erigontech#19981, and that
commit measured 100% in-sync), so the EL-side blocking this PR removes
is **not** what caused the 100→3% collapse. It is a real, separate cost
worth removing on its own merits: at tip it returns the consensus loop
to ~1 ms instead of ~260 ms (and avoids multi-second blocks when the
commit overlaps a background merge/prune burst).

## Why it's safe

The `<-done` was added (erigontech#19981) so a follow-up `AssembleBlock` could
safely acquire the EL semaphore. That guarantee is preserved without it:

- In `updateForkChoice`, the `defer e.semaphore.Release(1)` is
registered **first**, so it runs **last** — after every cleanup defer
(`ResetPendingUpdates`, `ClearWithUnwind`, overlay `Close`). Any op that
subsequently acquires the semaphore necessarily observes fully-settled
state.
- `ExecutionClientDirect.ForkChoiceUpdate` already retries
`AssembleBlock` (30× 200 ms) on semaphore contention, so a proposer FCU
racing an in-flight commit resolves itself.
- release/3.4 has no `<-done` and is the proven-good baseline.
- Non-merge FCUs send their result at the end of `updateForkChoice`
anyway, so their timing is unchanged.

## Test plan

- [x] `execution/engineapi` `TestEngineApi*` block-production suite (the
FCU→AssembleBlock path `<-done` guarded)
- [x] `execution/execmodule/...`
- [x] `cl/beacon/handler` `TestCaplinBlockProduction*`
- [x] `make lint` clean
- [x] Live-tip A/B (this branch vs main): FCU-response wall p50 260 ms →
1.2 ms, 0 gap errors over an epoch

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
Co-authored-by: info@weblogix.biz <admin@10gbps.weblogix.it>