fix(jupyter): keep kernel alive across transient peer disconnects (#34550)

## Summary

When a Jupyter client briefly disconnects between sending a request and
the kernel sending its reply, `KernelShellConnection::send` fails with
`ZmqError::Other("Destination client not found by identity")` (see
[zmq.rs
router.rs](https://github.com/zeromq/zmq.rs/blob/v0.5.0/src/router.rs#L100)).
That error propagated through `handle_shell_message` and `handle_shell`
via `?`, ending the spawned shell task. From the user's perspective, the
kernel just hangs — no future shell request gets a reply. The same hang
could happen on the control channel and when publishing iopub
status/output if a subscriber dropped briefly. This matches the symptoms
described in #20542 where "Client disconnected PeerIdentity(…)" is
logged and the kernel stops responding.

- Make `handle_shell` and `handle_control` resilient: read errors and
per-message handler errors are logged and the loop continues so the
kernel keeps accepting requests. The peer will re-issue the request
after reconnecting.
- Make `send_iopub` swallow transport errors. IoPub is a fire-and-forget
broadcast and its failures must not abort the shell-reply path the
client is waiting on.
- Harden the stdin and heartbeat loops the same way; the heartbeat now
yields on errors to avoid a tight spin if the socket is in a bad state.

Refactored `handle_control`'s message handling into a small
`handle_control_message` helper so its errors can be caught per-message
without losing the existing dispatch logic.

Fixes #20542.

Closes denoland/orchid#298

## Test plan

- [ ] `cargo check --bin deno` (passes locally)
- [ ] `./tools/lint.js` (passes locally)
- [ ] `./tools/format.js` (no diff)
- [ ] Manual: start `deno jupyter --kernel` from a Jupyter frontend,
verify the kernel survives the first-launch disconnect that previously
caused it to hang

Co-authored-by: divybot <divybot@users.noreply.github.com>
Co-authored-by: Divy Srivastava <me@littledivy.com>