SharePoint Graph Module - extend functionality with additional methods

[Drakonian]

What & why

The SharePoint Graph module currently supports creating files, folders, and list items — but offers no way to modify them after creation. Renaming an uploaded file or updating metadata on a list item are among the most common SharePoint integration scenarios, and their absence forces consumers to drop down to raw HTTP calls.

This PR closes that gap by adding update operations for both drive items and list items, backed by the standard MS Graph PATCH endpoints. It also upgrades the test infrastructure to properly cover multi-step operations that were previously untestable.

Linked work

Fixes #8317

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.
• Compiled System Application, Test Library, and Test projects — all three build clean, no new analyzer warnings.
• Ran UpdateDriveItem and RenameDriveItem against a test SharePoint site — file renamed successfully, response parsed into SharePoint Graph Drive Item record with updated name.
• Ran UpdateListItem with a fields payload (Title, custom columns) — PATCH succeeded, follow-up GET returned the full list item with updated values.
• Ran GetListItem for a single item — returned the expected record with all fields (ContentType, WebUrl, timestamps).
• Verified RenameDriveItemByPath and UpdateDriveItemByPath — path resolution + PATCH executed as two consecutive HTTP calls, both reflected in mock request log.
• Confirmed UpdateListItem_FollowUpGetFails test — when the GET after PATCH returns 404, the error is surfaced to the caller and request count is 2 (PATCH did fire).
• Ran all existing SharePoint Graph tests — no regressions. Sticky single-response mode works exactly as before.
• 22 new tests pass: 10 for drive item updates, 8 for list item operations, 4 for multi-response handler infrastructure.

Risk & compatibility

• All new methods are additive — no existing signatures or behavior changed.
• The test handler refactor preserves the original single-response contract; existing tests work without modification.

[github-actions]

Issue #8317 is not valid. Please make sure you link an issue that exists, is open and is approved.

[github-actions]

$\textbf{🟡\ Medium\ Severity\ —\ Style} \quad \color{gray}{\texttt{\small Iteration\ 1}}$

No newline at end of file

The file ends without a trailing newline (the diff shows the last added line without the standard Unix EOF newline). While AL compilation typically tolerates this, it causes noise in future diffs and violates standard file conventions in the repository.

Recommendation:

• Add a trailing newline character at the end of the file after the closing }.

    end;
}

Line mapping was unavailable, so this was posted as an issue comment.

_{👍 useful · ❤️ especially valuable · 👎 wrong - reply with why}

[pri-kise]

I know that this is only a test codeunit, but should we maybe document the current logic?
What I mean is that we should maybe make it clear that you shoud either use SetResponse once or AddResponse multiple times.

[pri-kise]

Could you maybe update?
https://github.com/microsoft/BCApps/blob/main/src/System%20Application/App/SharePoint/README.md