fix: Panic on missing operator in Reload handler

[ashnaaseth2325-oss]

1. SUMMARY

This PR fixes a runtime panic in the Reload event handler by safely handling missing operator channels instead of unwrapping. The change is localized to binaries/runtime/src/lib.rs in the run() function and aligns behavior with existing patterns used in other event handlers.

---

2. FIX

// BEFORE
operator_channels
    .get(&operator_id)
    .unwrap()
    .send_async(Event::Reload { operator_id: Some(operator_id) })
    .await;

// AFTER
let Some(operator_channel) = operator_channels.get(&operator_id) else {
    tracing::warn!("received Reload event for unknown operator `{operator_id}`");
    continue;
};

operator_channel
    .send_async(Event::Reload { operator_id: Some(operator_id) })
    .await;

---

3. VERIFICATION

Triggered a Reload event with a missing operator_id. Previously, this caused a panic; now it logs a warning and continues execution, confirming the fix.

[ashnaaseth2325-oss]

Hello @phil-opp,
Please review this PR.
Thanks!

[ashnaaseth2325-oss]

Hi @phil-opp, following up on this PR .
Could you please take a look when convenient? Thanks!

[ashnaaseth2325-oss]

Hi @phil-opp,
Please review.Thanks!

[phil-opp]

Sorry for the delay, but please don't ping me so often.

Needs a rebase, then we can merge

[heyong4725]

Hi @ashnaaseth2325-oss — thanks for spotting this panic and the clean fix. Closing this PR but the fix is being rescued and the credit is preserved in #1850.

Your analysis was right: the Reload handler was the only outlier in the surrounding match block — Event::Input and Event::InputClosed both already used the let-else + warn; continue; pattern, and Event::Reload was still unwrapping. Your fix made the three handlers consistent, which is exactly the right shape for this kind of map-lookup-then-send code path.

@phil-opp approved on 2026-03-29 with one ask — "Needs a rebase, then we can merge" — but you didn't get back to it. I'm sorry if the review tone discouraged you from following up; the rebase ask was just a mechanical update against main, not a substantive concern, and the work itself was solid.

#1850 is your commit cherry-picked onto current main verbatim — the git Author field stays as you (cherry-pick preserves authorship), and the rescue commit body explicitly references this PR. When #1850 lands, your name is on the merge commit history as the original author.

Two notes for next time, both small:

1. It's OK to wait longer between pings. Phil-opp's "please don't ping me so often" was a friendly process note, not a sign that the PR was unwelcome. For a small approved PR like this, even a single follow-up after 2-3 weeks would have been fine. You did good work; the PR was approved on the merits.

2. For "needs a rebase" asks, a one-line git pull --rebase origin main and git push --force-with-lease is usually all that's needed. If that ever feels intimidating on a small PR, mention it in a comment — reviewers can sometimes do it for you, or point at the conflict surface so you know what you're up against.

Reopen anything you'd like to revisit, or pick another good first issue when you have time. Thanks again for the contribution.