AppDataPaths::LocalAppData throws, not Get*

This code when run in an unpackaged app (say, a test environment) succeeds and returns an AppDataPaths instance, but the app-specific properties fail.

```c++
std::filesystem::path GetApplicationData(winrt::Windows::System::User user)
{
    auto paths = user ? winrt::Windows::Storage::AppDataPaths::GetForUser(user) : winrt::Windows::Storage::AppDataPaths::GetDefault();
    return std::wstring_view{ paths.LocalAppData().c_str() };
}
```

Updated the remarks to match the behavior.

Author: jonwis

windows.storage/appdatapaths.md

@@ -15,7 +15,7 @@ AppDataPaths returns paths to commonly used application folders based on the [KN
 ## -remarks
 This class returns paths that are always isolated per the caller’s context. For example, this will match expectations of cross-platform app developers who might have used “private” versions of documents in the past. There is no legacy COM interop interface for this type.
 
-Requesting folder locations from an app that doesn’t have a package identity will fail (for example, [GetDefault](appdatapaths_getdefault_846721868.md) and [GetForUser](appdatapaths_getforuser_2058550280.md) will both return null). This ensures there are no migration issues if an app depends on the per-app locations being shared (Win32), or if the app paths change when using the Desktop Bridge.
+Requesting app-specific folder locations from a an app without package identity (for example, [LocalAppData](appdatapaths_localappdata.md)) will fail. This ensures there are no migration issues if an app depends on the per-app locations being shared (Win32), or if the app paths change when using the Desktop Bridge.
 
 ## -see-also