[Quality] Standardize API error envelopes and correlation identifiers

[1nonlypiece]

Problem

Different backend paths expose inconsistent error shapes, making wallet and frontend recovery behavior unreliable and making production incidents hard to trace.

This issue requires a meaningful production implementation. Typo-only, documentation-only, formatting-only, dependency-only, or cosmetic changes do not satisfy the scope.

Objective

Define a versioned error envelope with safe client codes and a correlation ID propagated through logs and responses.

Scope

Map validation, authorization, conflict, upstream, and internal failures without leaking stack traces or secrets.

Acceptance criteria

• All public error paths return the documented envelope.
• Correlation IDs are stable across a request and included in structured logs.
• Internal details and credentials are redacted.
• API contract tests lock down representative status/code mappings.
• Existing CI/CD checks remain green.
• The PR explains the design, tradeoffs, test evidence, and any remaining limitations.
• The PR references this issue with Closes #{issue-number} or Fixes #{issue-number}.

Implementation notes

Implement only the stated behavior; keep unrelated refactors out of the PR.

Non-goals

• Do not remove tests merely to make CI pass.
• Do not introduce secrets, private keys, credentials, or mainnet-only values.
• Do not change unrelated APIs, UI surfaces, contract behavior, or deployment configuration.

Contributor application

Before starting, comment with relevant experience, a 1–4 bullet implementation approach, and an estimate for opening the first draft PR. Wait for maintainer assignment before coding. Only the assigned contributor is eligible for reward consideration.

Submission requirements

• Use PR title format [#<issue-number>] <short summary>.
• Check off each completed acceptance criterion.
• Include focused automated tests for success, failure, authorization, and boundary behavior where applicable.
• Include the validation commands and results in the PR description.
• Address maintainer review feedback before merge.

GrantFox reward consideration is based on the original scope, implementation quality, tests, security review, CI/CD results, review feedback, and follow-up stability; completion or merge alone is not a guarantee.

[guptakumarranjeet150]

Hello! I'd like to work on this issue.

I would love to take this on. My planned approach:

• Trace the regression in Disciplr-Org/Disciplr-backend causing [Quality] Standardize API error envelopes and correlation identifiers and implement a targeted, minimal fix.
• Add a reproduction test case to prevent any future regression.

Ready to deliver a clean, tested PR within 12–24 hours. Please assign!