fix(broadcast): survive the Credible RPC alignment window

[lean-apple]

Summary

An endpoint can briefly answer assertions are unavailable while a credible layer's assertion state catches up with the chain. This makes PCL wait through that window without ever risking a second transaction on the same nonce.

How the retry is safe

• PCL fills and signs the transaction once, then resubmits those exact bytes on every attempt. Same hash, same nonce, so a node that already holds it deduplicates the retry rather than accepting a second transaction.
• An already known answer counts as submitted — otherwise a send that succeeded but whose response was lost would turn into a spurious failure.
• Gas estimation is retried too, before anything is signed. Assertion rejections are reverts and stay terminal.
• Anything else fails on the spot.

Scaled to the endpoint

--with-credible-rpc (or PCL_WITH_CREDIBLE_RPC) says which kind of endpoint is being broadcast to:

Endpoint	Attempts	Wording
--with-credible-rpc	6, ~6s per step	Credible layer is realigning while submitting…
plain	3	Endpoint is unavailable while submitting…

The flag scales how long to wait, not whether to retry. A plain endpoint can produce the same refusal — behind a proxy, or a URL the operator did not realise fronts a Credible RPC — so gating the retry on the flag would turn a recoverable blip into a hard failure when the flag is wrong. The two are indistinguishable from the URL alone, so the kind is stated rather than probed.

Errors

If the window outlasts the retries, the error says whether anything was submitted:

• onchain.assertions_unavailable — nothing was signed or submitted, the nonce is unchanged, re-run the command.
• onchain.tx_submission_unconfirmed — carries the signed hash; check it before re-running, since a rebuilt transaction would reuse the nonce.

Resolves ENG-4467

[linear-code]

ENG-4467