certbot: `renew --once` exits 0 when the renewed hook fails

dstack/certbot/src/bot.rs から始め、renew_and_run_hook が更新フックの失敗をどのように報告しているかを追跡し、その後 cli/src/main.rs の --once パスを追ってください。daemon ループの現在のログ記録して継続する動作は維持しますが、フックが実行されないか正常に終了しなかった場合に、--once がゼロ以外の終了コードを返すようにしてください。関連する certbot のコマンドパスを使って、両方のセマンティクスを検証してください。

Follow-up to #924.

certbot renew --once is the cron/one-shot entry point. #924 made it invoke the renewed_hook (correct — a one-shot renewal that skips the reload hook leaves the serving process on the old cert), but hook failures are only logged:

// dstack/certbot/src/bot.rs
match std::process::Command::new("/bin/sh").arg("-c").arg(hook).status() {
    Ok(status) if status.success() => {}
    Ok(status) => error!("renewed hook failed with status: {status}"),
    Err(error) => error!("failed to run renewed hook: {error:?}"),
}
Ok(true)

So renew_and_run_hook returns Ok(true) regardless, and certbot renew --once exits 0 even when the hook never ran or exited non-zero. A cron job or systemd OneShot unit wrapping this sees success while the certificate on disk is new and the serving process is still holding the old one — exactly the failure that is supposed to be visible.

Swallowing the error is right for the daemon (the next interval retries), wrong for --once (there is no next interval).

Proposal

Split the two semantics. Options, roughly in order of preference:

1. Have renew_and_run_hook return the hook outcome (e.g. Result<Outcome> carrying hook_failed) and let the --once path in cli/src/main.rs turn a hook failure into a non-zero exit, while run() keeps logging and continuing.
2. Add a fail_on_hook_error: bool parameter, set from the once flag.

Either way the daemon loop must keep its current behaviour: a failing hook should not abort the loop.