GetDocumentInsider uses unsanitized documentName when generating output file path

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Describe the bug

### Description

The GetDocumentInsider CLI tool constructs the output file path using a user-provided
`documentName` value.

Although a sanitized version of this value is computed internally, the final output
file name is built using the original, unsanitized input. As a result, directory
separators or traversal sequences (e.g. `../` or `..\`) can influence the generated
file path.

This allows a crafted `documentName` value to escape the intended output directory
and cause files to be written to unintended locations.

This issue was previously reported to MSRC (VULN-168240) and was classified as a
non-serviciable security case.

---

### Steps to reproduce

1. Run the GetDocumentInsider CLI tool with a specified `--output` directory.
2. Provide a `documentName` containing directory traversal sequences, such as:
- `a/../b`
- `a\..\b`
3. Observe that the generated output file path may be influenced by these sequences
instead of being treated as a plain file name.

---

### Expected behavior

The output file path should always be derived from a sanitized version of
`documentName`, with no possibility for directory traversal or subdirectory creation.

---

### Actual behavior

The sanitized value is computed but not used when constructing the output file path.

---

### Affected code

`src/Tools/GetDocumentInsider/src/Commands/GetDocumentCommandWorker.cs`
Method: `GetDocumentPath(...)`

---

### Proposed fix

Use the sanitized document name when generating the output file path and treat
directory separators consistently across platforms.

---

### Additional context

A fix and regression test have already been prepared and will be submitted in a
follow-up pull request.

### Expected Behavior

The generated output file should always be created inside the specified output
directory, using a sanitized version of `documentName` that cannot influence the
resulting file path.

### Steps To Reproduce

No separate repro project is required. The issue can be reproduced directly by
invoking the GetDocumentInsider CLI tool with a crafted `documentName` value, as
described above.

### Exceptions (if any)

_No response_

### .NET Version

.NET SDK version: 8.0.x

### Anything else?

This issue was previously reported to MSRC (VULN-168240) and closed as non-serviciable
from a security perspective.