Test: assert the stale-build banner is VISIBLE in the GUI (browser-level), not just emitted into the $Banner slot #1809

Follow-up to the stale-build banner ("a newer build of this type is available — recycle to pick it up"). The implementation and its mesh-level tests land with that PR; this issue tracks the browser-level assertion the maintainer actually asked for:

"test that this banner appears in gui."

Why the shipped tests are not this test

StaleBuildBannerTest asserts the rendered control tree through a real mesh — it proves the server writes a banner control into the $Banner sidecar slot. It does not prove a user sees a banner. The Blazor binding (LayoutAreaView reducing the slot and rendering it above the content) is exactly where "renders empty" lives, and this codebase produced four separate false-greens in a single evening — one of which was every SocialMedia route returning HTTP 200 in 0.22 s while rendering nothing at all.

A server-side control assertion and a visible banner are different claims. Only the second one is what was requested.

🚨 Blocked on #1807

A browser test depends on npx playwright-core install --with-deps, which is the exact step #1807 documents hanging unbounded for 19 minutes and consuming a whole CI shard. Building this on that path before #1807 is fixed would be building on sand. Do this after #1807.

Required shape (do not weaken)

Against a real portal with DevLogin (the playwright skill's throwaway Colima/k3s portal — the Monolith has no language model but this flow needs none):

1. Seed a NodeType that compiles + an instance of it; open the instance page.
2. Negative control FIRST — assert the banner is absent. Without this, an always-on banner passes the positive half, which would put a "newer build available" notice above every page in the portal.
3. Write a different LatestAssemblyPath onto the type node via GetMeshNodeStream(typePath).Update(...). No recompile and no sleep — the state is a pure function of two strings (bound vs published), which is what keeps this from becoming a flake generator. Do not Task.Delay; wait on the DOM condition via Playwright's auto-waiting locator assertions.
4. Assert the banner is visible, by text or role on the rendered element. 🚨 Never a status code, never a control-model property — those are precisely the assertions that produced tonight's false-greens.
5. Assert the instance's own content is still rendered alongside it — the banner is an adornment, and a page that lost its content (or recycled itself) is the regression this feature replaced.
6. Prove it fails first: run against the pre-fix tree and confirm step 4 goes red. A test that cannot fail is not a test.
7. On failure, read the screenshot rather than inferring from the error text.

Code under test

• src/MeshWeaver.Graph/Configuration/StaleBuildBanner.cs — the $Banner sidecar renderer
• src/MeshWeaver.Graph/Configuration/NodeTypeEnrichmentHelpers.cs — WithStaleAssemblySelfHeal / ArmStaleAssemblySelfHeal (publishes the offer; must never recycle by itself)
• src/MeshWeaver.Blazor/Components/LayoutAreaView.razor + .razor.cs — the binding this issue exists to cover
• src/MeshWeaver.Layout/LayoutAreaSlots.cs — the shared slot constant

The banner feature is not "done" until this test exists. The implementation merges; this stays open.