If a cherry-pick process bombs out at some point due to a bug or unrecoverable service outage, it would be useful to be able to replay events in the bot or otherwise restart a process which was aborted or marked as a hard-fail.

Probably the easiest way to accomplish this would be to create new POST endpoints which directly access the event-driven logic of the core cherry-pick bot, effectively creating an RPC interface for the bot.

A limitation of this approach is that the admin user must know which parameters are required by the endpoint, and pass correctly formed parameters, since in a recovery scenario, the bot has likely written a "done_*" status to the database and removed the last-used function parameters. Perhaps we have enough leeway in the database to retain the last-called arguments regardless of the current done_* status of the pick. This should be investigated separately.