Address first-use friction: login clarity, navigation discoverability, and new-user onboarding (#468)

[ericwinger]

Summary

Addresses the actionable items from #468 — observations from the second new-developer first-use session (remote login, then a first attempt to browse code). The work groups into six areas; each is one focused commit (plus one merge of main), described below with what to expect and how to test it in a real editor window.

Where an item turned out not to need code, it's listed under "Items closed without code" with the reasoning.

What changed, and what to test

Log in to a stone first (any 3.7.x). Each area can be checked independently.

1. Login field help + connection feedback (items 1, 2, 3)

Expect: The login editor has a "Help me login" toggle (open by default for a new login) with per-field help; Host User / Host Password are marked optional. A left status-bar item shows a spinner while connecting, and on failure turns red and is click-to-explain. README / the walkthrough's connect page are rewritten to follow the UI order.
Test: Add a login and connect — watch the status bar go from connecting → (banner on success, see #2) or red on a bad password (click it to see why). Open the login editor and confirm the field help and the optional markers read clearly.

2. Green "connected" banner (item 3)

Expect: On a successful connect, a green ✅ Connected to <stone> banner flashes at the top of the GemStone Explorer's Dictionaries view for a few seconds.
Test: Connect and confirm the banner appears and then clears on its own. (VS Code status bars can't render green, so this is a TreeView.message banner — please eyeball placement.)

3. High Contrast selection visibility (item 6)

Expect: In the class browser, the selected row draws a full outline in the theme's focus-border color — visible in every theme and bold under High Contrast.
Test: Switch VS Code to a High Contrast theme, click a class/method, and confirm the selection is unmistakable. (Accessibility fix — please verify in a real HC window.)

4. Explorer selection stability + Methods-pane discoverability (items 7, 8)

Expect: The Explorer's Open Editors pane is gone (it reshuffled the sidebar and scrolled your selection out of view when you opened your first editor); a left status-bar Close N GemStone editor(s) button replaces its one-click close-all. The Methods pane opens each method in one reusable preview tab; a one-time hint explains this at the moment a click first replaces a previewed method, the pin command reads Keep Method Open (Pin), and the method-row tooltip spells out preview-vs-keep.
Test: Open a class, single-click several methods — confirm the selection no longer jumps away, and the one-time hint fires the first time a click replaces a method. Confirm the status-bar close-all button tallies and closes open GemStone editors.

5. Breadcrumb as a live class navigator + Back/Forward (items 8, plus #432)

Expect: The editor breadcrumb over an open method now drills into the stone at every level (dictionary → class → side → category → selector), so you can navigate sideways to sibling classes/methods without leaving the editor. Two title-bar GemStone Go Back / Forward buttons retrace the methods you've viewed (VS Code's own history can't, because methods share one preview tab). Also fixes #432: the senders/implementors hover no longer disappears when one of its two queries fails.
Test: Open a method, click through the breadcrumb dropdowns to reach a sibling method and the class definition. Use Go Back / Forward to retrace. Rest on a selector to confirm the senders/implementors hover still shows even on a stone without the RB plugin.

6. "Start Here" onboarding for a newly-connected user (item 10)

Expect: On connect, a purple GemStone - Start Here button appears in the status bar. Clicking it opens a quick pick — Browse a class, Search your code, Open a workspace, Take the tour. It stays put (it's unobtrusive) and is removed only via its own Hide the Start Here button entry; GemStone: Reset Getting Started brings it back. The same quick pick is always available from the Command Palette as GemStone: Start Here. The Get Started walkthrough also gained Browse classes and Search your code steps.
Test: Connect and confirm the button appears; click it and try each quick-pick action. Confirm dismissing the quick pick (clicking away) leaves the button in place, and that Hide the Start Here button removes it. Run GemStone: Reset Getting Started and reconnect to confirm it returns. Open Help → Welcome → Get Started with GemStone and confirm the two new steps.

Items closed without code

• Items 4 & 5 (accidental rename / ivar reorder): not reproducible — rename requires an explicit icon/menu plus a confirmation dialog, and ivar moves require an explicit arrow plus a destination quick pick. Dropped; reopen with a real accidental-repro case.
• Item 8, breadcrumb tooltip separators: the visible breadcrumb bar already uses ›. The remaining /-separated string is the editor tab's hover tooltip, which VS Code derives from the resource URI — no extension API can override it. Not fixable from the extension.
• Item 9 (selecting a class should update the editor): effectively resolved by items 6 + 8 — clicking a class now visibly populates the (larger, discoverable) Methods pane and the selection is clearly highlighted. We deliberately did not auto-open a class-definition tab on every click (visually noisy for read-oriented browsing). Left for the original tester to confirm.

Testing done

Fast gate green: ESLint, Prettier, tsc, and the full unit + integration suites — client 5912 · server 322 · mcp-server 92 (integration tests log into a live 3.7.x stone).

Closes #468