Unable to upload a file whose name contains a URL-encoded slash character

Describe the bug

For reasons of my own, I'm trying to upload a file with the following name: A%2FB%2BC+D.zip. This is a URL-encoded form of the string "A/B+C D.zip"

With version 4.54.0 I get a new directory named A and a file inside that directory named B+C+D.zip. This is obviously incorrect behavior.

With version 5.56.0, I get the following Microsoft.Graph.Models.ODataErrors.ODataError exception when calling CreateUploadSession:

"Name specified in the path doesn't match the name specified in the request body."
Code = "invalidRequest"

This too is incorrect behavior.

Update: if my filename contains an encoded + (i.e. "%2B") that also causes CreateUploadSession to throw the same exception. Clearly something is attempting to decode the name improperly.

Expected behavior

I'd expect the file to be uploaded with precisely the specified name, with no alterations performed by the underlying SDK or server side. None of the characters in the name are illegal, to the best of my understanding.

How to reproduce

5.56.0 code:

GraphServiceClient graph = ...;
string driveId = ...;
string folderId = ...;
string name = "A%2FB%2BC+D.zip";

Microsoft.Graph.Drives.Item.Items.Item.CreateUploadSession.CreateUploadSessionPostRequestBody body = new()
{
    Item = new() { Name = name }
};

UploadSession upload = await graph.Drives[driveId].Items[folderId].ItemWithPath(name).CreateUploadSession.PostAsync(body, cancellationToken: cancellationToken);

SDK Version

5.56.0

Latest version known to work for scenario above?

No response

Known Workarounds

No response

Debug output

No response

Configuration

Windows 11, x64, probably not specific to this configuration.

Other information

No response

Start by reproducing the supplied C# example through ItemWithPath(name).CreateUploadSession, comparing the encoded path with the request body's Name. Trace where CreateUploadSession constructs or encodes the path and filename, then verify that names containing %2F, %2B, and + are preserved exactly without triggering the path/body mismatch.