Unhandled return values in TTYPort::open

[NONnonHere]

@sirhcel Can you check this
Is it solving the TTYPort issue raised.

[sirhcel]

Thank you for preparing a PR @NONnonHere! And especially for also spotting that our OwnedFd could be used in TTYPort::pair too!

I streamlined up some spacing and line breaks in the initial commit with rustfmt and did some additional cleanup for use declarations and paths. Could you please add a changelog entry?

Please ignore CI issues related to MSRV (which fail due to dependencies no longer supporting Rust 1.59.0) and cargo-semver-checks (which seems to have an issue with Rust 1.94.0 and works just fine with an older release).

[sirhcel]

Thank you for updating the PR @NONnonHere! I found the changelog but there are also things puzzling me:

• What is behind merging the main branch back into this PR? I don't see the point in doing this for a PR in the first place and so I'm wondering why.
• I found the changelog in b195a50 but there are also a bunch of changes from de68572 in this commit. What is behind not adding the changelog on top of de68572 and instead duplicating changes?
• Why does 6f7b028 revert introducing OwnedFd in TTYPort::pair? I praised this a a good catch for improvement beforehand.

The module paths in tty.rs were somewhat inconsistent but this was nothing you touched. It was rather the moment for me to consistently use one or the other variant throughout the file while at it.

After all the stuff I'm wondering about here, I'd like you to ask about some of the ideas and your workflow out of curiosity because I haven't seen such things in the past:

• Where did you get the idea from to merge back the changes from main into the PR?
• Do you use a coding agent or LLM support for crafting commits?

[NONnonHere]

Hey @sirhcel, apologies for the inconvenience regarding the changelog. I pushed an automated update using claude agent as I was heading out and didn't give it the necessary review.