execution, cmd, docs: make FcuBackgroundCommit consumers wait out the async commit

[yperbasis]

Split out of #21293 (FcuBackgroundCommit groundwork). Defaults unchanged — the flag stays false; the flip is #22269's.

With the flag on, UpdateForkChoice returns before the MDBX flush+commit lands (the commit runs in a background goroutine holding the exec semaphore), and state-change notifications alone do not guarantee MDBX contains the head. This PR makes the flag's consumers robust to that:

Engine: busy-tolerant batch execution

A background FCU commit briefly holds the exec semaphore, so ValidateChain/UpdateForkChoice can routinely return Busy. execDownloadedBatch waits it out via retryBusy: a ctx-aware 50 ms poll with a periodic debug log so a stuck commit surfaces instead of hanging silently.

import: wait for the commit

import_cmd.InsertChain calls ExecModule.WaitIdle after driving forkchoice, so HeadBlockHash can't land in MDBX ahead of the header it points to — the state-change stream only confirms the dispatcher fired, not that the commit landed.

Flag documentation

--fcu.background.commit usage now states the actual contract: the FCU response returns before the MDBX flush+commit lands; remote rpcdaemon "latest" stays consistent but can lag for the commit duration. Same wording in ethconfig and the docs site (llms files regenerated).

Safety recap (with the flag enabled)

The bg goroutine releases the exec semaphore only after the commit completes and the overlay is unpublished, so FCU N+1 always reads FCU N's committed state; engine_newPayload/engine_getPayload serialize behind a pending commit (~commit-duration added latency; a SYNCING response in a pipelined burst is spec-valid and self-heals).