Apply backpressure to WebViewRenderer's unacknowledged render batch queue

[Kebechet]

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making.

Stop rendering while the WebView has too many unacknowledged render batches.

Description

WebViewRenderer currently produces, serializes and dispatches render batches without bound even when the JS side has stopped acknowledging them — e.g. on Android, where the OS demotes and freezes the out-of-process WebView renderer while the backgrounded host app keeps rendering. In that state we measured 207 unacknowledged batches accumulating over a 39-minute background period, each retaining its TaskCompletionSource plus everything registered against it (updated-component id arrays, cloned disposed-event-handler ids, _eventBindings entries) until acknowledged.

This ports the backpressure RemoteRenderer already applies for the equivalent scenario in Blazor Server:

• ProcessPendingRender() skips producing a new batch while the unacknowledged queue is at capacity. Pending renders stay coalesced in the base renderer's render queue, so retained state is bounded.
• NotifyRenderCompleted produces any deferred renders once an acknowledgement frees a slot.

The cap is an internal constant matching the default of CircuitOptions.MaxBufferedUnacknowledgedRenderBatches (10), so there is no new public API. Happy to make it configurable (the WebView equivalent of CircuitOptions) if that's preferred.

Two unit tests cover the behavior via TestWebViewManager: batches stop at the cap while acknowledgements are withheld (previously 21 batches were sent, unbounded), and the deferred renders flush as a single batch once one is acknowledged. TestWebViewManager gained a ReceiveRenderCompletedMessage helper mirroring ReceiveAttachPageMessage.

Notes:

• This intentionally does not address the companion issue [Blazor Hybrid] A single lost render-batch ack permanently corrupts WebViewRenderer's unacknowledged batch queue #68674 (a lost acknowledgement permanently corrupting the queue), but it bounds that bug's blast radius: the acknowledgement gap after a suspension can no longer exceed the cap.
• Debug-logging parity with RemoteRenderer's FullUnacknowledgedRenderBatchesQueue was left out to keep the diff minimal; I can add it if wanted.

Fixes #68675

[dotnet-policy-service]

Thanks for your PR, @Kebechet. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[Copilot]

Pull request overview

This PR adds backpressure to Blazor WebView rendering so WebViewRenderer stops producing new render batches when too many are outstanding (unacknowledged), resuming once acknowledgements arrive. It also includes an unrelated addition of a new ComponentBase protected API (IsAfterInitialization) with corresponding test and API-surface updates.

Changes:

• Add a cap (MaxBufferedUnacknowledgedRenderBatches) and gate ProcessPendingRender() to prevent unbounded accumulation of unacknowledged render batches in WebViewRenderer.
• Resume deferred rendering when a batch acknowledgement is received (NotifyRenderCompleted triggers ProcessPendingRender).
• Add tests/helpers for the WebView backpressure behavior, and separately add ComponentBase.IsAfterInitialization + tests + PublicAPI updates.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/Components/WebView/WebView/src/Services/WebViewRenderer.cs	Adds backpressure by gating rendering when the unacknowledged-batch queue reaches a fixed cap, and resumes on acknowledgement.
src/Components/WebView/WebView/test/WebViewRendererTests.cs	New unit tests validating that render batches stop at the cap and resume (flushing deferred work) after an acknowledgement.
src/Components/WebView/WebView/test/Infrastructure/TestWebViewManager.cs	Adds a ReceiveRenderCompletedMessage helper to drive acknowledgement behavior in tests.
src/Components/Components/src/ComponentBase.cs	Adds a new protected lifecycle-state property IsAfterInitialization and renames the internal init-tracking field.
src/Components/Components/test/ComponentBaseTest.cs	Adds unit tests covering the new IsAfterInitialization behavior under sync init, async init, cancellation, and exceptions.
src/Components/Components/src/PublicAPI.Unshipped.txt	Records the new ComponentBase.IsAfterInitialization protected API surface addition.

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[Kebechet]

Good catch — those ComponentBase commits were unrelated local WIP that ended up under the branch by mistake. Removed by rebasing onto upstream/main; the PR now only contains the WebViewRenderer change and its tests.

[Kebechet]

This file was included by mistake and is no longer part of the PR (see the sibling thread).