fix(cli): improve error handling for disabled payment channels

[rjan90]

Proposed Changes

Register ErrPaymentChannelDisabled in the RPC error registry so it properly survives RPC serialization. This allows errors.Is() to work correctly on the client side without needing string comparison fallbacks.

Changes:

• Add errPaymentChannelDisabled type and register it in api/api_errors.go
• Update node/impl/paych to use api.ErrPaymentChannelDisabled
• Simplify cli/info.go to only use errors.Is() check
• Remove PaymentChannelDisabledMessage constant (no longer needed)

Checklist

Before you mark the PR ready for review, please make sure that:

• Commits have a clear commit message.
• PR title conforms with contribution conventions
• Update CHANGELOG.md or signal that this change does not need it per contribution conventions
• New features have usage guidelines and / or documentation updates in
  • Lotus Documentation
  • Discussion Tutorials
• Tests exist for new functionality or change in behavior
• CI is green

[Copilot]

Pull Request Overview

This PR improves error handling in the lotus info command for disabled payment channels to prevent automation script failures. The change ensures the command exits with code 0 instead of code 1 when payment channels are disabled by default.

• Updated error message text for ErrPaymentChannelDisabled to be more concise
• Enhanced error detection logic to use both errors.Is() and string matching for robustness

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
node/impl/paych/paych.go	Updated error message text for ErrPaymentChannelDisabled to be more concise
cli/info.go	Added dual error detection using both errors.Is() and string matching to handle disabled payment channels

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[rvagg]

We should just be able to use the errors.Is for this but the catch is that the error needs to traverse the RPC boundary, we do that by registering error types in api/api_errors.go so both sides of the RPC know to encode it with a number, and decode it from that number, then it appears on the client side as the same error type and errors.Is works. Then we can do away with the string constant exported and just put the string into the error itself.

[rjan90]

Updated to traverse the RPC boundary in: 37f7e5e