[develop] Fix: Wrong type, member, and identifier names

[qiutongMS]

Fixes wrong type, member, and identifier names described in the develop docset fix report.

[qiutongMS]

Summary:
Thanks for fixing several incorrect identifiers and member names. I found two remaining must-fix issues in modified pages that would still mislead readers if this PR merged as-is.

Must-fix issues:

1. hub/apps/windows-app-sdk/migrate-to-windows-app-sdk/guides/windowing.md (Section "Compact overlay"): the updated paragraph still says AppWindowPresenterKind.RequestPresentation, but RequestPresentation is a method on AppWindowPresenter, not on the AppWindowPresenterKind enum. The table immediately below uses the correct API name, so the section is currently internally inconsistent.
2. hub/apps/develop/files/pickers-save-file.md (Section "Save a document with FileSavePicker"): the page now says in step 2 that PickSaveFileAsync returns PickFileResult, but earlier in the same procedure it still says readers save data via the returned StorageFile. Those two statements conflict and leave the return type unclear.

[qiutongMS]

Summary

I found one blocking issue in the updated windowing guidance. The rest of the fixes look good, but this API reference still needs correction before the PR is merged.

Must-Fix Issues

#	File	Line/Section	Issue	Severity
1	hub/apps/windows-app-sdk/migrate-to-windows-app-sdk/guides/windowing.md	Section "Compact overlay"	The prose still says ApplicationViewMode.TryEnterViewModeAsync, but TryEnterViewModeAsync is a method on ApplicationView, not on the ApplicationViewMode enum. This leaves an incorrect API reference in a modified sentence.	must-fix

[qiutongMS]

Review result: CHANGES_REQUESTED

I found one must-fix issue in the current PR state.

• File: hub/apps/develop/files/pickers-save-file.md
• Sections: "Save a document with FileSavePicker" and step 2 (around lines 43 and 125)
• Issue: PickFileResult is the correct return type for PickSaveFileAsync, but the new wording says it contains both the path and the file name. The official API surface documents Path; it does not expose a separate FileName member. This also conflicts with the sample below, which only uses result.Path.
• Why it matters: Readers may go looking for a non-existent property or misunderstand what data the picker actually returns.

Suggested fix: rephrase those sentences to say that PickFileResult contains the saved file path, and mention that the file name can be derived from the path if needed.

[qiutongMS]

Summary: I reviewed the latest diff and the full modified pages. The fixes correct the referenced type/member/identifier names, the modified links resolve, and I didn't find any new technical or whole-page quality issues that block merge.

No must-fix issues.