fix(shell): show who is signed in in the avatar menu

[imneov]

What type of PR is this?

• bug fix
• feature
• cleanup / refactor (no behaviour change)
• documentation
• install / chart
• CI / tooling
• breaking: API, config key, chart value, or CRD field changed

What this PR does and why

The avatar menu drew one line, name · role, and nothing else about the session. With server.auth.disabled it drew only that line: the two entries were dropped rather than replaced, so in that mode the menu opened with nothing in it — a dropdown that looks broken next to the one Rise Global's console has.

• The header now shows the avatar, the name, the role and, when console has a User CRD to read from, the email.
• The rows and their disabled state come from userMenuState(me) in web/src/shell/user-menu.ts, next to userMenuIdentity(me), so both auth modes are one small tested function instead of an inline !me.authDisabled.
• With auth disabled the state is visible without opening anything, and without adding an element to the bar: the user button itself turns amber — background, icon, name, a dot on the avatar — and its tooltip carries 登录已关闭，当前为管理员身份 (Sign-in off — acting as the administrator). In that mode the menu draws no entries at all — console can honour neither the password change nor the sign-out — and carries the same sentence where they would be. Signed-in installs keep both entries live. The text names the state, not the reader — server.auth.disabled makes every request the administrator, it does not make every account one. That mode's decision is unchanged and recorded (docs/console-design.md, "Running without a login": there is no session to end and no stored password to change, and /api/me returns authDisabled for exactly this).
• Signed-in installs are unchanged: both entries live, no line.

Which issue(s) this PR fixes

Fixes #60

How it was tested

• web/: npm run typecheck, npm test (276 passed — the 4 new cases in src/shell/user-menu.test.ts cover both auth modes and the email-only-when-console-has-one rule), vite build.
• Built the branch together with the overlay-ring fix (fix(web): keep the ring border on focused overlays #59, needed for the panel's border) and served it to the live preview:
  • auth disabled (what both previews run): the user button computes background: warning/10, color: warning, box-shadow: inset 0 0 0 1px warning/45, the avatar warning/20, a 10px dot with a 2px ring in the bar's own colour, title = the sentence, and the chip's box is unchanged at 90×36 — no element added, no layout shift; the menu then holds the identity and the sentence full-width and zero [data-slot=dropdown-menu-item] nodes;
  • the same treatment checked on the dark header (mixed-nav): amber chip, amber text, and the dot's ring matches the dark bar;
  • signed in (the same build behind a local /api/me proxy reporting authDisabled: false and an email): the chip computes a transparent background with no dot, no notice is rendered, and both 修改密码 and 退出登录 are present;
  • signed in (the same build behind a local /api/me proxy reporting authDisabled: false and an email): avatar + admin + 管理员 + the email + 修改密码 + 退出登录, both enabled and no line.
• Also started a login-enabled local preview from this branch (:32609, server.auth.jwtSecret set, the same cluster) to check the real path: the app redirects to /login and /api/me answers 401 without a token.
• Screenshots for both modes were reviewed during the session.

Checks

• go test ./... and gofmt -l . is empty
• npm run typecheck && npm test && npm run build in web/ (if web/ changed)
• helm lint --strict helm/console (if the chart changed)
• Docs updated where behaviour, a config key or a chart value moved
• No internal hostnames, IPs, registries or credentials

Notes for reviewers

Shell only: Layout.tsx, two locale files, a new user-menu.ts + its test, and a CHANGELOG line. Nothing about the auth-disabled decision changes — the entries are disabled where console cannot honour them, and the menu names the state and shows the identity it does know.

Release note

The top-bar avatar menu shows who is signed in — avatar, name, role and, when console has one to read, the email. On an install with `server.auth.disabled` the user button turns amber and the avatar carries a dot, so the state is visible without opening the menu, and the menu says why it offers no password change or sign-out.

[imneov]

Merging on LF's instruction (2026-10-13) through the documented flow: issue #60 filed, PR rebased on current main (4622bf9, which already carries #59 and resolved the CHANGELOG conflict), all checks green (gate, go, publish, web), squash per recent practice for a single-commit PR. No reviewers are required on main (0 required approvals), so no approval is outstanding.