Fix issue in discarding newly created entities which has multi-level of nested children

[yashmeet29]

Describe your changes

Fix: NoSuchElementException during draft discard when attachments exist on a grandchild composition entity

handleDraftDiscardForLinks was calling getAttachmentPathMapping on the root entity being discarded. This method traverses nested compositions to find attachment entities, but buildEntityPath always used the direct child entity as the namespace when constructing the map key — regardless of how deep the actual attachment entity lived.

For example, given the structure:
SourcingEventsServiceEntity
└── TeamAddinsServiceEntity (direct child, no attachments)
└── TeamsServiceEntity
└── attachments (grandchild)
buildEntityPath produced SourcingEventService.TeamAddinsServiceEntity.attachments instead of SourcingEventService.TeamsServiceEntity.attachments. When revertLinksForComposition appended _drafts and called model.findEntity(...), the entity was not found, causing NoSuchElementException.

The fix:
Added getDirectAttachmentPathMapping in AttachmentsHandlerUtils that only processes direct sap.attachments.Attachments compositions on the root entity — no nested traversal.
Updated handleDraftDiscardForLinks to use getDirectAttachmentPathMapping for Path 1 (root entity direct attachments).
Nested attachment handling is already correctly implemented in the existing revertNestedEntityLinks → processNestedEntityComposition path (Path 2), which calls getAttachmentPathMapping on each direct child individually — meaning targetEntity always equals the entity where the attachment actually lives.
Additionally fixed unsafe Optional.get() calls without isPresent() checks in DBQuery.getuploadStatusForAttachment.

Any documentation

The issue only manifests when attachments are defined on a grandchild or deeper composition of the draft-cancelled entity. Applications where attachments are directly on the first-level child (like the standard demo app) are unaffected.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist before requesting a review

• I follow Java Development Guidelines for SAP
• I have tested the functionality on my cloud environment.
• I have provided sufficient automated/ unit tests for the code.
• I have increased or maintained the test coverage.
• I have ran integration tests on my cloud environment.
• I have validated blackduck portal for any vulnerability after my commit.

Upload Screenshots/lists of the scenarios tested

• I have Uploaded Screenshots or added lists of the scenarios tested in description

Single-tenant Integration tests: https://github.com/cap-java/sdm/actions/runs/28505618401
Multi-tenant Integration tests: https://github.com/cap-java/sdm/actions/runs/28516956119