The About page is unreachable: three call sites navigate to /_settings/… but the node is registered at _Setting #1817

Every in-app link to the About page 404s. The page itself is fine — the links point at a
path that is not registered.

This is now in three call sites, the newest added by #1791 (the build chip), which
copied the literal rather than deriving it. Filing it properly because it keeps
propagating: it was two call sites when first noticed, and adding a feature made it three.

How to reproduce

1. Sign in to any portal (reproduced on a local instance at memex.localhost:8443,
   build 3.0.0-rc4.ci.0+8278244204d7e3d0cc95b1461c825383cf0875a9).

2. Click the version chip in the top bar — or open the profile/avatar menu (top right)
   and choose About or What's New.

3. The browser navigates to /_settings/GlobalSettings/About and renders:

   Page not found
   Page not found: '_settings/GlobalSettings/About' does not match any registered
   address pattern.

   Please double-check the url you have entered.

Same for /_settings/GlobalSettings/WhatsNew.

Note on the chip specifically: Activate() only navigates when the chip is in an
informational state. When an update is available it takes the Refresh branch
(Navigation.Refresh(forceReload: true)), which works. So the 404 is hit exactly when a
user clicks to ask "what am I running?" — the question the chip exists to answer.

Cause

The registered node is at _Setting — singular, capital S:

src/MeshWeaver.Graph/Configuration/GlobalSettingsNodeType.cs:21

public const string SettingsPath = "_Setting";

All three navigation call sites hardcode _settings — plural, lowercase:

src/MeshWeaver.Blazor.Portal/Components/UserProfile.razor.cs:170,172

private void NavigateToWhatsNew() => Navigation.NavigateTo("/_settings/GlobalSettings/WhatsNew");
private void NavigateToAbout()    => Navigation.NavigateTo("/_settings/GlobalSettings/About");

memex/Memex.Portal.Shared/SelfUpdate/PlatformUpdateChipView.razor:128 (added in #1791)

Navigation.NavigateTo("/_settings/GlobalSettings/About");

_settings (lowercase) is also a reserved satellite/schema segment name in the
cross-schema Postgres/Snowflake routing — an unrelated meaning, not an alias for this node.

Suggested fix

Derive the path from GlobalSettingsNodeType.SettingsPath at all three call sites instead
of repeating a literal, so a fourth call site cannot reintroduce this. If the framework
project cannot reference the constant from Memex.Portal.Shared, a shared route-builder
helper would serve the same purpose.

Why this went unnoticed

The About page is reached only from the profile/avatar menu, not from the Settings
navigation tree — so the naming (AddAboutSettingsTab, grouped with AddApiTokensSettingsTab
and friends) points a reader at the wrong surface. #956's originating PR #897 describes it
as "Settings → About", which is where I first looked and did not find it.

Context: #956

#956 asked for a way to verify a deployment is current. Its code fix shipped (#985, the
running-vs-latest verdict on the ungated About tab; #1006, the anonymous GET /api/version),
and the issue was closed — but the About half has never been reachable in the UI because of
this bug. #1791's header chip now answers the same question without navigating anywhere,
so this is no longer blocking the original use case; the About page and What's New are
still unreachable, and What's New has no equivalent replacement.

Separate, smaller: two UX points on the chip (happy to split these out)

1. The full version string is too long for the top bar. It renders as 48 characters of
hash. The component's own CSS already concedes this — under 720px it hides the version text
entirely, with the comment "which is still on the tooltip and on the About page". A short
form (rc4.ci.0) or glyph-only with the full string on hover would read better; the tooltip
mechanism already exists.

2. Neither the chip nor the About page shows WHEN the running build was deployed. A
version identifies the build but not when it started serving. Deployment time — rendered in
the viewer's timezone — is the thing that actually answers "is this current?" at a glance,
and it is the question that repeatedly came up while diagnosing whether a portal had rolled
forward at all.