Add retry mechanism for failed time triggers

[s8sato]

Is it acceptable that time triggers can fail without offering a retry opportunity, unlike user-submitted transactions?

[takemiyamakoto]

Current behavior is "no automatic retry."

Time triggers are executed during block application as synthetic time-trigger entrypoints, not as queued user-submitted transactions. When a time trigger fails, Iroha rolls back the staged state changes for that trigger chain, records the failure (TriggerCompleted(Failure) / block error), and continues committing the block.

That also means a one-shot scheduled trigger is effectively at-most-once for its matched time slot: once the block interval that matched it has passed, we do not automatically enqueue a retry in a later block. For periodic triggers, the failed occurrence is not retried either; the trigger only has a chance to run again at its next scheduled tick.

So if the expected contract is "keep retrying until success," the answer is no: the current implementation does not provide that. It is closer to best-effort execution with observable failure, rather than durable job semantics.

I think this is acceptable only if we document time triggers with that weaker guarantee. If we want stronger semantics, retry should be treated as a separate enhancement with persisted, deterministic retry state (for example retry budget / next-attempt schedule), so every peer derives the same behavior.