Add a Display impl for WalletError guaranteed to never include secret material, with a compile-time-checked test

[Emmyt24]

Description

Complementing the audit-and-harden fix elsewhere in this batch that reviews every WalletError variant's fields for accidental secret exposure, this ticket adds the actual Display implementation (if one doesn't already exist via thiserror or similar) as the single, deliberate place user/log-facing error text is produced — rather than relying on Debug's auto-derived output (which, depending on struct field visibility and derive macros used, can be far more verbose and harder to audit than a hand-written Display) being what actually reaches logs or API error responses.

Requirements and Context

• Confirm whether WalletError currently derives Debug only, or also has an explicit Display/std::error::Error impl (likely via thiserror, check Cargo.toml).
• If Display isn't hand-controlled per variant, add explicit per-variant messages (via thiserror's #[error("...")] attributes, which this project may already use elsewhere) so exactly what's user-facing is deliberate, not whatever Debug's derive happens to produce.
• This should land alongside (or after) the WalletError secret-exposure audit fix elsewhere in this batch, using its findings to write each variant's message.

Suggested Execution

Branch: feat/wallet-core/safe-display-for-walleterror

Implement Changes

• Add/tighten thiserror::Error #[error("...")] messages for every WalletError variant in crates/wallet-core/src/error.rs.
• Confirm every call site currently relying on Debug formatting for a WalletError (in logs or API error mapping) is unaffected or intentionally updated to use Display instead.

Test and Commit

• every_walleterror_variant_has_an_explicit_display_message_containing_no_secret_material (parametrized across all variants, reusing the secret-exposure audit's findings).
• Run cargo test -p octo-wallet-core locally before committing.

Example Commit Message

feat(wallet-core): add explicit, audited Display messages for every WalletError variant

WalletError's user/log-facing text needed confirmation that it comes from a deliberate,
per-variant Display implementation rather than whatever Debug's derive happens to
produce. Adds explicit thiserror messages for every variant, informed by the parallel
secret-exposure audit.

Guidelines

• Coordinate with the WalletError secret-exposure audit ticket — use its findings to write each variant's message rather than duplicating that research.
• Reference this issue with Closes #<issue-number> in the PR description.
• Open your pull request against the dev-branch branch — PRs targeting main will not be reviewed.

[ranjeet150]

Hey team,

I can tackle Add a Display impl for WalletError guaranteed to never include secret material, with a compile-time-checked test. Proposed implementation roadmap:

• Analysis: Inspect current behavior and edge cases in Octo-Protocol-org/Octo-Protocol
• Core Implementation: Add comprehensive test coverage for Add a Display impl for WalletError guaranteed to never include secret material, with a compile-time-checked test verifying edge cases and failure scenarios.
• Quality Assurance: Ensure zero flake and 100% green pass rate across the test suite.

I am ready to start immediately—please feel free to assign this to me!

[CARTEL-L]

@CARTEL-L has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Hi! I’m a full-stack developer with a strong blockchain background. I’d love to handle this issue and can deliver a clean, reliable solution. Kindly assign it to me.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @CARTEL-L to this issue.

[Marshaltechnology]

@Marshaltechnology has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Hi , i want to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Marshaltechnology to this issue.

[fadesany]

@fadesany has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Hello maintainer, i would like to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @fadesany to this issue.

[samuelelijah585]

@samuelelijah585 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Hello, I've reviewed the issue and its acceptance criteria, and I'm confident I can deliver a solution that meets the requirements. I'd appreciate it if you could assign this issue to me. Thank you!

ℹ️ Repo Maintainers: To accept this application, review their application or assign @samuelelijah585 to this issue.

[janetobande]

@janetobande has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Hello, pls assign me this issue. I have been able to handle an issue similar to this and I'm very sure i can do this very fast and to your satisfaction
Pls do consider my application.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @janetobande to this issue.

[Alhajichild]

@Alhajichild has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

Hey would love to work on this

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Alhajichild to this issue.

[mazikush365]

@mazikush365 has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

I’m interested in this issue because error messages can unintentionally expose sensitive wallet data, especially when Debug output is used in logs or user-facing paths. I’d review every WalletError variant and its fields, then implement a deliberate Display representation that exposes only safe, useful error information. I’d also add compile-time-checked coverage to ensure the implementation remains in place and cannot accidentally fall back to secret-bearing Debug output. I’ll keep the change focused on safe error formatting and regression protection.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @mazikush365 to this issue.

[k2ghostyou]

@k2ghostyou has applied to work on this issue as part of the Stellar Wave Program's 9th wave.

i would love to work on this issues

ℹ️ Repo Maintainers: To accept this application, review their application or assign @k2ghostyou to this issue.

[drips-wave]

Congratulations, @k2ghostyou! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on September 30, 2026.

🧑‍💻 @k2ghostyou: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊