Add a customizable status bar for user-pinned topics

[bracyw]

What

A customizable, always-available status bar in Argos where the user pins whichever telemetry topics they want to watch at a glance, so those readings stay visible (sticky while scrolling) instead of being hardcoded per page.

Why

Grew out of the LV Battery banner work (#705): that banner is a hardcoded, single-purpose readout pinned to the eFuses page. Generalizing it — let the user choose which topics fill a sticky at-a-glance bar — would serve any "I always want to see X" need without building a bespoke component each time.

Design direction

A proposed architecture — hoist the bar to the app shell, backed by a status-bar service — is captured in the design comment below: #709 (comment)

Logged as a raw idea via log-future-addition.

[bracyw]

Design direction: hoist the status bar to the app shell, backed by a service

Captured from a design discussion. The foundation is the #705 status bar (PR #707), which is intentionally page-owned for now.

The constraint that shapes this

Today the status bar lives inside the eFuses page and gets its chip through content projection. If we hoist a single bar up to the app shell — above the router outlet, rendered once and shared by every page — content projection stops working: a page cannot project content across the router outlet into a bar that sits outside it. Hoisting therefore forces us off projection and onto a registry that pages (and users) push chips into. That registry is exactly this feature.

Recommended mechanism: descriptor + service

A root-provided StatusBarService holds two signals — page defaults and user-pinned — and exposes a computed merge of the two as the chip list. The app shell hosts one status bar and renders the service's chips generically. Each page registers its own defaults on init: the eFuses page, for example, registers an LV Battery chip (topic VCU/LV/voltage, unit V, with the status dot driven purely by the firmware low-voltage fault flag, never a hardcoded cutoff). User pinning plus persistence is the same signal — the other half of the merge, loaded from and saved to local storage. The existing info-value-display component (config-driven value + widget) is prior art for the generic chip renderer.

Alternative considered: CDK Portal

Pages keep bespoke chip components and teleport them onto the shell bar. Heavier plumbing, and only worth it if a chip cannot be expressed as data. The LV chip is a trivial descriptor, so the descriptor model wins.

What carries over from #707

The status-bar presentational shell — sticky container, collapse/expand affordance, projection slot — is reused as-is. The app shell becomes its host, and projection still works there because the shell is the bar's direct parent. Only how chips get in flips from page-projection to the service. The LV chip becomes the first registered chip, expressed as a config.

Lifecycle to bank now

Page defaults need clearing on navigate-away (a DestroyRef or effect in the page, or a router-event reset in the service) or stale chips linger onto the next page. The bar renders nothing on pages that register none.

Sticky-fix note

The page-host block display that gives the sticky bar a full-height containing block moves to the shell host when the bar hoists.