Correct ValidateContainerView doc example for the neutral TFM alias

The override example showed a backend-specific platform type as the
parameter, but PlatformView is a per-TFM alias that resolves to
System.Object on the non-platform build. An external backend copying the
example verbatim gets CS0115 ("no suitable method found to override"),
which is exactly what happened while writing the external backend test
handler in this PR.

Show the override taking `object` and testing the concrete wrapper type
with a pattern match instead, and state the aliasing rule explicitly so
the constraint is discoverable from the API docs rather than from a
compiler error.

Docs-only; no API or behavior change.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Author: Redth

src/Core/src/Handlers/View/ViewHandler.cs

@@ -247,11 +247,15 @@ protected void SetContainerView(PlatformView? containerView)
 		/// <para>The .NET MAUI iOS, Mac Catalyst and Tizen handlers use this to require a
 		/// <see cref="Platform.WrapperView"/>. An external backend that shadows <see cref="ContainerView"/> with its own
 		/// wrapper type should do the same.</para>
+		/// <para>Note that <paramref name="containerView"/> is typed as the platform view type of the target framework,
+		/// which is <see cref="object"/> on the non-platform (neutral) build. An override must therefore match that type
+		/// rather than the backend's own platform type, and test the concrete wrapper type with a pattern match.</para>
 		/// <example>
 		/// <code language="csharp">
 		/// public new MyWrapperView? ContainerView => (MyWrapperView?)base.ContainerView;
 		///
-		/// protected override void ValidateContainerView(MyPlatformView containerView)
+		/// // The parameter type is the target framework's platform view type - 'object' on the neutral build.
+		/// protected override void ValidateContainerView(object containerView)
 		/// {
 		///     if (containerView is not MyWrapperView)
 		///     {