refactor: Replace manual resource handling with try-with-resources (#4593)

# Description of Changes


Explanation on try-with-resource:

> Many resources in Java need be closed after they have been used. If
they are not, the garbage collector cannot reclaim the resources'
memory, and they are still considered to be in use by the operating
system. Such resources are considered to be leaked, which can lead to
performance issues.
> 
> Java 7 introduced the try-with-resources statement, which guarantees
that the resource in question will be closed.
> 
> try (InputStream input = Files.newInputStream(path)) {
>   // "input" will be closed after the execution of this block
> }
> 
> This syntax is safer than the traditional method using try, catch, and
finally and hence should be preferred.

https://rules.sonarsource.com/java/tag/java8/RSPEC-2093/

<!--
Please provide a summary of the changes, including:

- What was changed
- Why the change was made
- Any challenges encountered

Closes #(issue_number)
-->

---

## Checklist

### General

- [ ] I have read the [Contribution
Guidelines](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/CONTRIBUTING.md)
- [ ] I have read the [Stirling-PDF Developer
Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md)
(if applicable)
- [ ] I have read the [How to add new languages to
Stirling-PDF](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md)
(if applicable)
- [ ] I have performed a self-review of my own code
- [ ] My changes generate no new warnings

### Documentation

- [ ] I have updated relevant docs on [Stirling-PDF's doc
repo](https://github.com/Stirling-Tools/Stirling-Tools.github.io/blob/main/docs/)
(if functionality has heavily changed)
- [ ] I have read the section [Add New Translation
Tags](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/HowToAddNewLanguage.md#add-new-translation-tags)
(for new translation tags only)

### UI Changes (if applicable)

- [ ] Screenshots or videos demonstrating the UI changes are attached
(e.g., as comments or direct attachments in the PR)

### Testing (if applicable)

- [ ] I have tested my changes locally. Refer to the [Testing
Guide](https://github.com/Stirling-Tools/Stirling-PDF/blob/main/devGuide/DeveloperGuide.md#6-testing)
for more details.

---------

Signed-off-by: Balázs Szücs <bszucs1209@gmail.com>

app/common/src/test/java/stirling/software/common/util/PDFToFileTest.java

@@ -5,7 +5,9 @@ import static org.junit.jupiter.api.Assertions.assertNotNull;
 import static org.junit.jupiter.api.Assertions.assertTrue;
 import static org.mockito.ArgumentMatchers.any;
 import static org.mockito.ArgumentMatchers.anyList;
+import static org.mockito.ArgumentMatchers.anyString;
 import static org.mockito.ArgumentMatchers.argThat;
+import static org.mockito.Mockito.lenient;
 import static org.mockito.Mockito.mockStatic;
 import static org.mockito.Mockito.when;
 
@@ -47,10 +49,21 @@ class PDFToFileTest {
 
     @Mock private ProcessExecutor mockProcessExecutor;
     @Mock private ProcessExecutorResult mockExecutorResult;
+    @Mock private TempFileManager mockTempFileManager;
 
     @BeforeEach
-    void setUp() {
-        pdfToFile = new PDFToFile();
+    void setUp() throws IOException {
+        // Mock the TempFileManager to return real temp files
+        lenient()
+                .when(mockTempFileManager.createTempFile(anyString()))
+                .thenAnswer(
+                        invocation ->
+                                Files.createTempFile("test", invocation.getArgument(0)).toFile());
+        lenient()
+                .when(mockTempFileManager.createTempDirectory())
+                .thenAnswer(invocation -> Files.createTempDirectory("test"));
+
+        pdfToFile = new PDFToFile(mockTempFileManager);
     }
 
     @Test