Improve retry behavior by distinguishing retryable broadcast errors

## Problem

The current retry mechanism in transaction submission treats almost all errors as retryable, except for `context.Canceled` and `context.DeadlineExceeded`.

This can lead to unnecessary retry attempts for errors that are clearly non-recoverable (e.g., malformed transactions, authorization failures), reducing efficiency and potentially masking real issues.

## Proposed Solution

Refine the retryable error classification by introducing a more precise distinction between retryable and non-retryable broadcast errors.

This could include:

* Identifying error types returned by the orderer client
* Avoiding retries for deterministic failures (e.g., invalid transaction structure)
* Retrying only for transient failures (e.g., network issues, temporary unavailability)

The implementation should remain simple and avoid over-engineering.

## Scope

* Update `isRetryable` logic in `submit.go`
* Optionally extend tests to validate retry behavior for different error types
* No changes to public APIs

## Benefits

* Reduces unnecessary retry attempts
* Improves efficiency and clarity of failure handling
* Makes retry behavior more aligned with real-world distributed system practices

## Notes

This builds on the existing retry mechanism and focuses on improving its correctness rather than expanding its scope.