feat(app): wrap duty callbacks with the retry executor

[varex83agent]

Closes #534.

Wires Pluto's async retry executor (crates/app/src/retry.rs, previously with zero call sites) into the five duty-pipeline callbacks charon wraps in core.WithAsyncRetry (core/retry.go, applied in app/app.go as core.WithAsyncRetry(retry.New(deadlineFunc)) at v1.7.1): fetcher.fetch, consensus.participate, consensus.propose, parsigex.broadcast and bcast.broadcast. Each stitch now dispatches its work onto the executor with a per-duty deadline from the beacon-derived deadline calculator and returns immediately, so a transient beacon-node or network error is retried with backoff instead of dropping the duty on this node.

Consensus is wrapped for async dispatch only (no retry), matching charon's note that ConsensusParticipate/ConsensusPropose "don't require retrying but they should be called async" — re-running a failed QBFT instance for the same duty would be wrong. Because Pluto's generated beacon client collapses non-2xx responses into message-less typed errors, charon's isTemporaryBeaconErr substring heuristic cannot be ported verbatim; the retry decision is fixed per call site instead and documented inline as an accepted divergence.

Adds the wiring test the issue asks for: a transient 503 on the attestation-data endpoint is retried and the attester duty still completes through to consensus.propose (verified to fail when the retry policy is removed).

Co-Authored-By: Bohdan Ohorodnii 35969035+varex83@users.noreply.github.com