feat(app-onboard): make onboarding the BrowserOS first-run experience (#2427)

* feat(app): stop opening the in-app onboarding tab on install

Fresh installs opened app.html#/onboarding from the background worker. That
flow is being replaced by the browser's own first-run experience, and leaving
this in place would open both on a fresh profile.

Only the auto-open is removed here; the routes still resolve if navigated to
directly, so this stays reversible while the new flow lands. Side-panel setup
on install is untouched.

* feat(build): bake the app-onboard resources into BrowserOS

The onboarding SPA is selected at build time and both products baked the
neo onboarding. Give the BrowserOS product its own onboarding component so
each product ships the flow it actually uses.

- Add the app-onboard prod asset build (script, descriptor, tests) and the
  root build scripts, mirroring the neo onboarding pipeline.
- Register app-onboard as a release component with its own resource family,
  R2 allocation probe, and release workflow on the app-onboard/v* tag.
- Declare app-onboard as the BrowserOS product's onboarding component and
  gate the onboarding download and copy operations by product, so each
  binary receives only its own SPA. The grit pak name and id stay shared;
  only the source bytes differ.
- Resolve the onboarding archive name and build command from the product's
  component instead of hardcoding the neo one.
- Reserve both onboarding versions for nightlies so each product pins the
  version of the component it bakes.

* feat(browser): run the onboarding first-run for BrowserOS too

The onboarding WebUI, its importer handler, and the first-run controller
are already compiled into both product binaries; only a product check in
ShouldShow kept BrowserOS from ever reaching them. Now that BrowserOS
bakes its own onboarding SPA, drop that check so the first-run flow runs
for both products.

On completion, BrowserOS appends the agent extension's AI settings page to
the first-run tabs, so the browser opens where the user finishes connecting
a provider or coding agent. A chrome:// document cannot navigate there
itself, and BrowserOS neo keeps routing itself, so the tab is added only
for BrowserOS.

The earlier NeutralizeUpstreamFirstRun call is left in place: it only sets
kFirstRunFinished, which ShouldShow never reads, so it cannot pre-empt the
onboarding branch, and it still stands down the upstream first-run on later
launches once onboarding is complete.

* refactor(app): remove the retired in-app onboarding flow

The browser now owns first-run, so the in-app welcome, profile, connect-apps,
sign-in, and demo screens no longer have an entry point. Remove the route
group and the screens behind it, along with the profile sync that only fed
that flow and the analytics events only it fired.

The features showcase moves out of the onboarding directory and keeps its
own route, since it is reached from settings and is not part of the retired
flow. Its click event keeps its current name so the existing analytics
series stays continuous.

Storage is trimmed to just the two keys the flow owned. The import and
sign-in hint keys, the post-signin redirect path, and the first-run confetti
flag all stay: they belong to the new tab and chat surfaces, which continue
to read them.

* fix(build): pin the app-onboard resource download to its exact version

The latest-to-version rewrite is keyed by R2 prefix, and the new
app-onboard family had no entry, so a published BrowserOS build kept the
mutable latest selector and would embed whichever onboarding bytes that
alias happened to point at instead of the version it reserved.

Add the family so the key resolves like every other pinned resource, and
cover it in the resolver tests, including the case where no override is
supplied.

Author: DaniAkash

.github/workflows/nightly-browseros.yml

@@ -109,7 +109,7 @@ jobs:
         env:
           EXTENSION_SHA: ${{ needs.extension.outputs.release_sha }}
           EXTENSION_VERSION: ${{ needs.extension.outputs.version }}
-          ONBOARDING_VERSION: ${{ needs.reserve.outputs.onboarding_version }}
+          ONBOARDING_VERSION: ${{ needs.reserve.outputs.app_onboarding_version }}
           SERVER_SHA: ${{ needs.server.outputs.release_sha }}
           SERVER_VERSION: ${{ needs.server.outputs.version }}
           SOURCE_SHA: ${{ needs.reserve.outputs.source_sha }}
@@ -243,7 +243,9 @@ jobs:
           BROWSEROS_CONFIG_URL: ${{ secrets.BROWSEROS_CONFIG_URL }}
           BROWSEROS_REPO: ${{ steps.build_inputs.outputs.browseros_repo }}
           BROWSEROS_SERVER_RESOURCE_VERSION: ${{ needs.server.outputs.version }}
-          BROWSERCLAW_ONBOARD_RESOURCE_VERSION: ${{ needs.reserve.outputs.onboarding_version }}
+          # Per-build onboarding resource pin; BrowserOS bakes the app-onboard
+          # component, so it reserves that app's version.
+          BROWSERCLAW_ONBOARD_RESOURCE_VERSION: ${{ needs.reserve.outputs.app_onboarding_version }}
           BUNDLED_EXTENSIONS_MANIFEST_URL: ${{ steps.build_inputs.outputs.browseros_repo }}/updates/extensions/bundled-manifest.xml
           BUNDLED_PRODUCT_EXTENSION_VERSION: ${{ needs.extension.outputs.version }}
           CHROMIUM_SRC: ${{ steps.chromium_workspace.outputs.chromium_src }}