fix(web): consult pluginTabs before the hardcoded root title in resolvePageTitle

[ygd58]

Fixes #80891.

Problem

resolvePageTitle() special-cased the root path ("/") and returned the hardcoded "Sessions" title before it ever consulted pluginTabs. A dashboard plugin declaring tab: { path: "/example", override: "/" } correctly renders at the root once manifests load, but the shell's page header still showed "Sessions" instead of the plugin's own label.

Fix

Swapped the two blocks: check pluginTabs first, fall back to the hardcoded "Sessions" title only when nothing overrides "/". Behavior for everyone else is unchanged.

Verification

Added the requested regression test plus a sanity test. Verified as a genuine regression by reverting the fix and confirming the new test fails with "Sessions" instead of the plugin's label.

7/7 pass in resolve-page-title.test.ts; 167/167 across the broader web/src/lib test suite (no regression).

[spfcraze]

This was generated by AI during triage.

Summary:
The new regression test's comment calls the "/" key the plugin's "own path, not the override target's", but pluginTabMeta is keyed by m.tab.override ?? m.tab.path (web/src/App.tsx:479) — for tab: { path: "/example", override: "/" } the "/" entry is the override target.

Problems:

• web/src/App.tsx:479 builds each entry as path: m.tab.override ?? m.tab.path, so for tab: { path: "/example", override: "/" } the entry's "/" key comes from the override while the plugin's own path is /example; the parenthetical added in the new test of web/src/lib/resolve-page-title.test.ts ("its own path, not the override target's") states the inverse of that.

Solution:
As a wording that matches the code: "registered in pluginTabs under the "/" key (the override target's path, not the plugin's own)".

---

Checked against 83128d3 — the tip of fix/resolve-page-title-plugin-root-override when this was written — and 261aef5, main at the same moment.

[ygd58]

Confirmed, fixed in 972a870. pluginTabMeta keys each entry by m.tab.override ?? m.tab.path, so the "/" entry comes from the override target, not the plugins own path -- the comment had it backwards. Comment-only change, no logic or assertion touched. 7/7 pass.