Should `stack_error` be just `error`?

n0-error is trying to give me stack traces. That sounds neat, but I don't think we argue the case well enough in documentation.
The primary API is oriented around "stack errors", which makes me want "normal errors". Imho it would be better to bend the API to be more in the vein of "n0-error is a kind of error, and it's neat trick is stack traces when RUST_BACKLOG=1". I don't want to think about stack traces, I want to think about errors.

As an "application dev" (as opposed to a library dev), I have a semi-permanent sense of unease that I'm holding n0-error wrong. This is most pronounced when writing a custom protocol, where I'm often calling methods on the struct that implements the protocol, which themselves return anyhow::Errors. I recall jumping in here & y'all were like "oh yeah, don't do that". That's the specific guide I really want: a walkthrough of how anyhow & n0-error interact.

We can totally decide to file this as "won't-fix" for any proposed API changes if they don't make sense. In all cases I'd like more documentation that'll hold my hand & tell me it's ok to use something other than anyhow::Result

No files or tests are named. Start by reading the existing n0-error API documentation and the anyhow::Result integration described in the issue; done means providing an application-developer walkthrough that explains the intended error-handling pattern and whether any API naming changes are warranted.