fix: don't assume 422 are validation errors

[konstantinoscs]

Until now, all UNPROCESSABLE_ENTITY errors were assumed to be validation errors. With quotas, that's no longer true.

We need to change the way we process errors a bit.

Example:

[Copilot]

Pull Request Overview

This PR fixes error handling to properly display all UNPROCESSABLE_ENTITY errors instead of assuming they're all validation errors. With the introduction of quotas, 422 status codes can now represent different types of errors beyond validation failures.

• Refactors error output logic to extract and display full error details from API responses
• Changes UNPROCESSABLE_ENTITY error messaging from validation-specific to generic
• Updates error content extraction to use actual response content instead of error string representation

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
crates/tower-cmd/src/util/apps.rs	Updates error content extraction to use response content instead of error string
crates/tower-cmd/src/output.rs	Refactors error handling to display full error details and removes validation-specific messaging

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

This error message is confusing because 'syntactically correct' typically refers to syntax parsing, but UNPROCESSABLE_ENTITY (422) usually means the request was well-formed but semantically invalid. Consider a clearer message like 'The request could not be processed due to semantic errors or business rule violations.'

Suggested change

	error("The request was syntactically correct, but the Tower API couldn't process it.");
	error("The request could not be processed due to semantic errors or business rule violations.");

[konstantinoscs]

I'm ok with changing this I guess. Tower hivemind drop your opinion as well...

[bradhe]

Discussed on a Hangout and this approach will work well for now!