Preserve API failures across resource delete commands

[rgarcia]

Summary

Stop treating HTTP 404 responses as successful deletion. A 404 can mean that the selected project is invalid, not just that a resource is already absent. Preserve the API's error code and message through the standard CLI error formatter and return a nonzero exit status.

• Apply the same behavior to browsers, profiles, proxies, extensions, credentials, credential providers, managed auth connections, telemetry destinations, and API keys. API keys already returned an error but replaced the API's message with a misleading missing-key message.
• Propagate errors from profile/proxy lookups before confirmation instead of treating them as absent resources or continuing to a delete request.
• Remove the browser success message's "already absent" claim and document the exit-status behavior.

Compatibility

Actual missing-resource 404s now also return an error rather than exit successfully. Successful API responses and cancelled confirmations retain their existing behavior. This intentionally does not distinguish project and resource 404s by parsing error messages.

No SDK/dependency changes. Non-delete 404 handling is unchanged.

Verification

• make test passed (go vet ./... and go test ./...).
• make build passed.
• go test -race ./cmd ./cmd/proxies -run 'Test.*Delete' -count=1 passed.
• Added HTTP-fixture coverage for project/resource 404s, 403, 409, 500, successful deletion, and profile/proxy lookup failures. Tests verify the preserved SDK error and API message.
• Exercised the built CLI against a local HTTP fixture: all nine commands exit 1 for invalid-project and missing-resource responses and exit 0 for successful responses (27 checks).
• make lint: 66 existing findings. Direct golangci-lint run --new-from-rev=origin/main: 0 issues.
• Full diff self-review/deslop completed. No live API calls or real resource deletions were used for testing.