Refactoring: Use let-else for errors

Nobody has claimed this yet.

Currently a lot of errors are handled in a manner similar to:

```rust
let dev = device.open_device(&hidapi)
.or(Err(Error::Transport(TransportError::ConnectionFailed)))?;
```

These errors are tricky to track down. Now that we're using the `tracing` crate fully, it would be best to rewrite these using `let-else` syntax, ie.:

```rust
let Ok(dev) = device.open_device(&hidapi) else {
error!(?hidapi, "Failed to open device");
return Err(Error::Transport(TransportError::ConnectionFailed));
}
```

If the error is relevant to the message, first consider if the method being called should be instrumented to automatically log errors in their context:
```rust
use tracing::instrument;

#[instrument(skipall, err)]
pub fn open_device(&self, dev: &HidDevice) {
...
```

If this is not possible, we can instead use match statements at the point of invocation:

```rust
let dev = match device.open_device(&hidapi) {
Ok(dev) => dev,
Err(err) => {
error!({ %err, ?hidapi }, "Failed to open device");
return Err(Error::Transport(TransportError::ConnectionFailed));
}
};
```

Search the Rust codebase for the `.or(Err(...))?` error-handling pattern and inspect `device.open_device` first. Replace applicable cases with `let-else`, tracing instrumentation, or invocation-site matches as appropriate; done means errors are logged with relevant context while preserving the existing error result.

Written by the indexing model from the issue text.