Fixes problem with hardcoded contentType in AAS Env

[aaronzi]

Description of Changes

This PR fixes a small bug that got introduced in #791 where the AAS Environment used a hardcoded contentType in setFileToFileElement

[Copilot]

Pull Request Overview

This PR replaces the previous hardcoded “application/octet-stream” contentType in setFileToFileElement with a dynamic value pulled from the SubmodelElement’s contentType field, falling back to null if none is provided.

• Use the SubmodelElement’s contentType instead of a fixed value
• Default to null when contentType is missing or blank

Comments suppressed due to low confidence (2)

basyx.aasenvironment/basyx.aasenvironment-core/src/main/java/org/eclipse/digitaltwin/basyx/aasenvironment/base/DefaultAASEnvironment.java:202

• [nitpick] Add unit tests for setFileToFileElement covering scenarios where contentType is provided, blank, or null to ensure the repository call behaves correctly in each case.

		submodelRepository.setFileValue(submodelId, fileSMEIdShortPath, getFileName(inMemoryFile.getPath()), contentType, new ByteArrayInputStream(inMemoryFile.getFileContent()));

basyx.aasenvironment/basyx.aasenvironment-core/src/main/java/org/eclipse/digitaltwin/basyx/aasenvironment/base/DefaultAASEnvironment.java:201

• If contentType is null, setFileValue may not handle it as intended. Consider falling back to a default value such as "application/octet-stream" when the field is empty or missing.

		String contentType = (fileSME.getContentType() != null && !fileSME.getContentType().trim().isEmpty()) ? fileSME.getContentType() : null;