feat(error): let DetailedError contribute structured next_actions to error envelopes

[mguerrero3-godaddy]

Summary

• Adds DetailedError::error_next_actions() -> Vec (default-empty, mirroring error_fix()) so error envelopes can carry structured, agent-executable next actions instead of only a plain-text fix string.
• CliCoreError::Detailed now captures these eagerly at wrap time (before the source is erased to dyn Error), and both build_error_envelope and build_detailed_error_envelope thread the value through instead of hardcoding next_actions: Vec::new().

Implements for ticket DEVEX-983

Test plan

• cargo fmt --all --check
• cargo clippy --all-targets -- -D warnings
• cargo test --all-targets

Manual verification

Setup:

# In the cli repo, temporarily override the engine dependency:
cd cli/rust
# Edit Cargo.toml → cli-engine = { features = ["pkce-auth"], path = "../../cli-engine" }
cargo build --release && cp target/release/gddy ~/.local/bin/gddy

Test WITHOUT the fix (baseline):

cd cli-engine && git checkout main
cd cli/rust && cargo build --release && cp target/release/gddy ~/.local/bin/gddy
# <command to reproduce the issue>
# Expected: <describe broken behavior>

Test WITH the fix:

cd cli-engine && git checkout <this-branch>
cd cli/rust && cargo build --release && cp target/release/gddy ~/.local/bin/gddy
# <same command>
# Expected: <describe fixed behavior>

Cleanup:

# Revert cli/rust/Cargo.toml back to:
# cli-engine = { features = ["pkce-auth"], version = "<published-version>" }

[jpage-godaddy]

I'm not sure about this. I think it might be redundant with the fix addition to the envelope that @qcai-godaddy made here: #65

Do you think there are cases where having next actions that are not considered fixes make sense?

[mguerrero3-godaddy]

Do you think there are cases where having next actions that are not considered fixes make sense?

Fair question. Digging in, that fix and next_actions aren't structurally the same (single string vs. a list of executable commands with typed params), and next_actions reuses the same mechanism pagination already ships on the success side (middleware.rs). So it's not really duplicating Qi's PR logic.

That said, nothing in this repo populates error_next_actions() today, transport::Error doesn't override it, and my only example is a test I wrote to verify the wiring works, not a real use case.

I'd say it is less "is this redundant with fix" and more if is it worth merging the capability now, ahead of a real consumer needing it, or should we hold it until we have an actual error type that needs more than one structured follow-up?

[jpage-godaddy]

I guess it doesn't hurt to allow next actions for errors. I can at least imagine legitimate cases for it.