fix(fossology): rollback clearingState when upload preparation fails

[Aman-Cool]

When triggering a FOSSology upload, the handler marks the release as SENT_TO_CLEARING_TOOL in CouchDB before it actually tries to fetch the attachment and upload it. If anything goes wrong during that prep work (missing attachment content, transient DB error, etc.), the exception just bubbles up and the clearing state never gets reset; leaving the release permanently stuck with no way to re-trigger from the UI.

This fix wraps the risky part in a try-catch so that on any failure, we reset the step back to NEW and write NEW_CLEARING back to the document before re-throwing, the same cleanup that already happens on a normal upload failure response.

Issue: NA

Suggest Reviewer

@GMishx

How To Test?

1. Create a release with a source attachment, then delete the attachment content document directly from CouchDB (simulating a stale reference or failed upload).
2. Trigger FOSSology from the release page.
3. Before fix: the release gets stuck at SENT_TO_CLEARING_TOOL even though nothing was sent. Re-triggering is blocked.
4. After fix: the release returns to NEW_CLEARING and you can retry once the attachment issue is resolved.

No new tests added; the existing FOSSology handler tests cover the upload step; manual reproduction is straightforward with a CouchDB document edit.

Checklist

Must:

• All related issues are referenced in commit messages and in PR

[Aman-Cool]

Hey @GMishx, found a bug where a FOSSology trigger failure leaves the release permanently stuck at SENT_TO_CLEARING_TOOL with no way to retry from the UI. Fix just adds a rollback for the cases that were slipping through. Pretty small change, let me know if anything looks off!

[Sandipmandal25]

just one concern about exception handling added a comment below

[Aman-Cool]

@Sandipmandal25, Wrapped the rollback call in its own try-catch so if CouchDB is also down, the rollback failure gets logged but swallowed and the original exception always propagates cleanly.