Reconsider status responses

Some status errors in NeoFS are known and self-describing. But there are also "general errors" with 1024 status codes and some "good" human-readable messages.

Expected Behavior

If I have a general error, I expect NOT a general message that can help me understand what is happening. E.g. session token does not relate to the container a request is trying to change:

status: code = 1024 message = could not execute SetEACL request: session token validation: wrong container: 

Current Behavior

Only the last error in the errors chain is attached:

status: code = 1024 message = wrong container: 

Possible Solution

1. errors.Join for meaningful errros inside a package? (like session tokens errors can be wrapped with a common session token error with detailed errors so the Unwrap does not unwrap more than it is needed as the package thinks)
2. Make all the low-level errors well described and have more context than they have now? (can be a huge work)
3. Attach the full error chain if it is a 1024 error? (chain could be too long and too golang specific)
4. Attach 1-2 more errors from the lowest one? (a strange rule can fix smth but not all the cases)

Steps to Reproduce (for bugs)

Any 1024 "general" error case (like incorrect session token; even though session token error may become another status case, there always be some "general" errors that should be described correctly).

Context

https://github.com/nspcc-dev/neofs-node/blob/996b1eae7bd1f1ad5693758b38c9c025523842ac/pkg/services/util/sign.go#L225-L229

Regression

No.

Your Environment

0.40.0

Start with pkg/services/util/sign.go around lines 225-229 and reproduce a 1024 general error such as an incorrect session token. Review how the error chain becomes the status message, then compare the proposed errors.Join, fuller low-level messages, and partial-chain approaches. Done requires an agreed behavior that preserves useful context without producing an unsuitable error chain.