fix(share_plus): fail with a PlatformException instead of crashing when there is no implicit view

[TanimowoObaloluwaDavid]

Description

share() on Windows terminates the process when the plugin is registered without an implicit view, as happens for apps built on a bare FlutterEngine (experimental windowing, enable-windowing: true).

GetWindow() dereferenced the result of registrar_->GetView() unconditionally:

HWND SharePlusWindowsPlugin::GetWindow() {
  return ::GetAncestor(registrar_->GetView()->GetNativeWindow(), GA_ROOT);
}

PluginRegistrarWindows::GetView() returns nullptr unless the embedder created an implicit view, which is the deprecated accessor for exactly the reason that no single implicit view exists once multi-window is in play. So the null dereference happens before any Dart-side error can be raised: no exception, no log line, the process is just gone.

This PR makes GetWindow() null-safe and turns the crash into a catchable PlatformException (no_implicit_view) from the share handler, so apps can handle or surface the failure instead of dying.

Anchoring the dialog to a specific window would need GetViewById(), and the plugin has no way to be told which window to use, so that is deliberately left out of scope.

Related Issues

• Fix [Bug]: [share_plus] Windows: hard crash on share() when the app has no implicit view (multi-window) #3962

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
• I titled the PR using Conventional Commits.
• I did not modify the CHANGELOG.md nor the plugin version in pubspec.yaml files.
• All existing and new tests are passing.
• The analyzer (flutter analyze) does not report any problems on my PR.

Notes on verification: this change is Windows-only C++, so it is not covered by the Dart unit tests and I could not compile it locally (no Visual Studio toolchain available in my environment). Windows CI is the compile check. I have not been able to exercise the multi-window path at runtime.

Breaking Change

• Yes, this is a breaking change. Apps that were relying on the process aborting are unaffected in practice; apps on a bare FlutterEngine now get a PlatformException on share() instead of a silent process kill. No API or pubspec change.
• No, this is not a breaking change.