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

[rjan90]

Proposed Changes

Improve error handling in lotus info command for disabled payment channels. Use both errors.Is() and string matching to detect ErrPaymentChannelDisabled, preventing exit code 1 when EnablePaymentChannelManager is false.

This change fixes automation script failures (reported by the ChainSafe team) that occurred because the command previously exited with code 1 instead of 0 when payment channels were disabled (by default).

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.}

[Copilot]

The string matching approach is fragile and creates tight coupling between the error message text and the error handling logic. If the error message changes in the future, this condition could break. Consider using only errors.Is() for type-safe error detection, or if string matching is necessary for backwards compatibility, use a constant for the string to avoid magic strings.

[rjan90]

Added a constant PaymentChannelDisabledMessage in 3d6b865

[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.