Add message-driven RestartExecutions to FlowsManager

[stidsborg]

Summary

Moves RestartExecutions into the per-type FlowsManager so it can claim and resume flows targeted by fetched messages, rather than only delivering to already-live flows.

• Restart + resume: unowned target flows are claimed via RestartExecutionsWithoutMessages, then each is resumed through a new non-generic IFlowRestarter (implemented explicitly by Invoker<TParam,TReturn>) using the in-hand messages — no re-claim or extra store round-trip, since the store's return value carries the flow snapshot the restarter needs.
• Reopen un-claimable positions: flows that could not be claimed have their positions dropped from the message-clearer's ignore-set without deleting them from the store (their actual owner still needs them). ReopenPositions is added to IMessageClearer.
• Wiring: FlowsManager now receives non-nullable MessageClearer and ClusterInfo; FunctionsRegistry sets the restarter on each per-type manager right after the Invoker is constructed (late-bound, since the invoker doesn't exist when GetOrCreate runs).

Notes / follow-ups

• IFlowRestarter lives on the Invoker (not InvocationHelper) because the restart drives the user-function execution loop (_inner).
• The ScheduleRestartFromWatchdog delegate is unchanged and still used by the PostponedWatchdog path; it has the same signature as IFlowRestarter and could be converged later.
• Still open: Invoker.PrepareForReInvocation does not yet push RestartedFunction.StoredMessages into the QueueManager, so a restarted flow currently re-fetches its messages from the store rather than consuming the in-hand copies.

🤖 Generated with Claude Code