HDDS-16163. Fix TrashOzoneFileSystem error handling on LEGACY buckets

[len548]

What changes were proposed in this pull request?

On legacy buckets (non-FSO path), delete() and rename() in TrashOzoneFileSystem could report success even when the underlying OM write failed:

1. RenameIterator / DeleteIterator swallowed errors — submitRequest() failures were caught, logged, and iteration continued as if nothing failed.
2. Return values were ignored — top-level delete() / rename() always returned true, even when iterate() returned false.
3. Null OMRequest was not handled — if createOMRequest() failed, a null request could be passed to submitRequest() or fail without propagating failure to the caller.

This fix propagates these delete/rename failures from the LEGACY trash iterator path instead of always returning true.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-16163

How was this patch tested?

Add UT written by Cursor with Composer 2.5 model

[sadanand48]

Thanks @len548 for the patch, LGTM, pending CI

[sadanand48]

@len548 Looks like there are merge conflicts. could you please resolve them?

[len548]

Thank you @sadanand48 for pointing out the merge conflict. I kept TestTrashOzoneFileSystem from master unchanged and renamed one in this PR to TestTrashOzoneFileSystemLegacyBucket, since the two suites use different configs.