fix: several small memory leaks in Windows code - #53853

Overview

This PR touches three Windows-only C++ files: shell/browser/notifications/win/windows_toast_notification.cc, shell/browser/ui/file_dialog_win.cc, and shell/common/language_util_win.cc. All three changes correct COM/WRL smart-pointer usage bugs that cause reference leaks: (1) using GetAddressOf() instead of ReleaseAndGetAddressOf() when re-populating a ComPtr that may already hold a reference, (2) reusing a single CComPtr<IShellItem> across loop iterations without releasing the prior reference, and (3) using a raw, never-released IVectorView<HSTRING>* instead of a ComPtr.

Security risks

None. These are internal resource-management (reference-counting) fixes with no new external input handling, no IPC surface, no sandbox/context-isolation implications, and no public API change. Worst-case impact of the pre-existing bugs was a handle/reference leak, not memory corruption or a security boundary issue.

Level of scrutiny

I traced each change against its surrounding code (read the full Initialize() function, the file-dialog loop, and the language-preferences function) and confirmed each fix is mechanically correct and doesn't change control flow or introduce new failure paths: ReleaseAndGetAddressOf() is the standard WRL idiom for this exact scenario; moving the CComPtr declaration inside the loop is the standard ATL idiom to force a release each iteration; and the ComPtr wrapper for langs is used identically to the raw pointer via operator-> for the two subsequent calls (get_Size, GetAt), so no follow-on Release() call was dropped. The change is small, self-contained, follows well-established COM/ATL/WRL patterns, and does not touch security-sensitive or cross-process code paths, so I judge this at the low end of required scrutiny.

Other factors

The PR is Windows-specific and not something CI can meaningfully exercise for the leak itself (these are resource-leak fixes, not behavior-visible bugs), which matches the checklist author's claim of manual build/test verification. There is a maintainer comment in the timeline after the last commit, but with no visible content or explicit CHANGES_REQUESTED/unresolved-thread state, and my own read of the current diff, I found nothing incorrect or unaddressed to flag. No CODEOWNERS restriction is evident on these paths, and the change is small enough that I'm confident a human need not scrutinize it further.