[webium] Sync initial Toolbar state via frame-specific WebUI property

The WebUI Toolbar startup latency suffers from Mojo pull roundtrips
when requesting the initial navigation controls and icon states during
browser window initialization.

To resolve this, this CL introduces a mechanism to serialize and push
the initial toolbar state browser-side during resource initialization.
We serialize the required initial state into a JSON string and push it
via a frame-specific WebUI property using
`RenderFrameHost::SetWebUIProperty()`. This allows the frontend to
retrieve the initial state synchronously using
`chrome.getVariableValue('initialState')` and parse it during
initialization.

(A) Alternative Approaches

We considered several designs to deliver the initial state:

1.  **Profile-wide `loadTimeData`**: Rejected because profile-wide
    data can leak window-specific state, like navigation button
    status, across different windows on the same profile.
2.  **Frame-specific `loadTimeData` via custom frame data binder and
    `SetTopFrameSpecificLocalizedStrings()`**: Rejected because
    `WebUIDataSource` and its backend are intentionally designed to be
    profile-shared. Attempting to bend it to support frame-specific
    data goes against this design.
3.  **Asynchronous `RenderFrameHost::SetWebUIProperty()`**: Rejected
    because the properties were delivered asynchronously, introducing
    race conditions where the initial state was not guaranteed to be
    available before the frontend TS constructor executed.

(B) Implementation Details

To ensure the properties set by `SetWebUIProperty()` are reliably
delivered to the renderer synchronously on startup before the TS ctor
runs, we update `WebUIExtensionData` to bind its Mojo receiver using
`rf->GetTaskRunner(TaskType::kInternalNavigationAssociated)`.
This binding is conditionally scoped to when
`features::kInitialWebUISurfaceSync` is enabled, avoiding priority
inversion on general WebUI pages.

A new `DependencyProvider` interface is introduced to supply this
controls state, abstracting whether the state comes from the actual
browser window or a default fallback during background prewarming. To
prevent dangling pointers and use-after-free vulnerabilities when views
are torn down or detached while `WebContents` remains alive,
`WebUIToolbarUIDependencyProviderUserData` stores a
`base::WeakPtr<DependencyProvider>` and explicitly removes its
`UserData` in `~WebUIToolbarWebView()`.

In the `chrome/` layer, the controller uses this mechanism inside
`WebUIToolbarUI::WebUIRenderFrameCreated()` to populate and inject the
initial state.

During background Pre-Navigate prewarming, before the actual
`WebUIToolbarWebView` exists and can act as the real dependency
provider, the WebContents UserData is missing. In this case,
`PopulateInitialState()` directly injects default-initialized dict
values, ensuring that the TS ctor can still initialize synchronously
with safe defaults without requiring an auxiliary fallback class. As
soon as the window adopts the prewarmed WebContents, the real window
provider overwrites the fallback via Mojo.

A test-only property `isInitializedSyncForTesting_` is exposed in
TS to verify synchronous initialization on startup.

Bug: 530370659
Change-Id: I8dc92a1420c70657377e47c5dd0c15bbb9191521
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/8049002
Reviewed-by: Thomas Lukaszewicz <tluk@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Ming-Ying Chung <mych@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1667690}