Say which view the dashboard is on, reach the machine's settings, and stop pushing views down

[ntatschner]

What this does

Fixes four dashboard faults, found by walking every view in Chrome against a sandboxed dashboard and measuring rather than eyeballing.

• The machine's settings were unreachable. The "What this machine is set to" fold and the Settings page were both id="settings". getElementById returns the first, so fillSettings unhid the page instead of the fold, and the fold stayed hidden under the runs list. That's been true since the Settings page arrived (0324df9, 20 Sep): where notices go, the trigger token, the listen address and the office art couldn't be changed from the dashboard. The fold is now id="machine" and moves onto the Settings page when that page is first drawn. Until then, a rule keeps it hidden in the runs pane.
• Switching view told you nothing.
  • Focus stayed on the button, and the heading read "Runs on this machine" over every view.
  • The address never changed, so Back and bookmarks couldn't reach a view.
  • Now each view has its own heading ("The office", "Who asked whom", "When runs ran", "Waiting to run", "Terminal"). A view you choose takes focus at that heading. One the page opens on, or one Back returns to, doesn't.
  • The address carries #office, #graph and so on, the page opens on the view it names, and Back and Forward move between views. The token stays in the query string.
• List-only controls pushed every view down. "Run a team", "Make a team…", "Run one on a schedule…", "Clear out runs" and "How the roles have been doing" sat above the office, the graph and the timeline, which therefore began about 280 px down. They now show on the list only.
• A short view pushed the whole page down. The page is a grid at least a window tall, and nothing said which row takes the spare height. On Waiting and Settings the header row grew to 192 px over 69 px of header. The content row takes it now (grid-template-rows: auto minmax(0, 1fr), and auto auto minmax(0, 1fr) on narrow windows).

The dashboard guide gains a short paragraph on the address and focus.

Evidence

• New DashboardServerTests, each failing before the change:
  • Every_id_on_the_page_is_used_once: before, it found {"settings"}.
  • A_view_says_what_it_is_and_takes_the_focus.
  • A_short_view_does_not_push_the_page_down.
• The_page_offers_a_way_to_start_one matched the exact tag <details class="start">. The fold now has an id, so the string was updated; the test's point is unchanged.
• Dashboard tests: 144 passed. Full suite: 3072 passed, 22 skipped, 0 failed.
• Chrome at 1280 by 800, measured with a script on each view:
  • Focus lands on the view's heading, and the heading and address change.
  • The totals ledger is at 109 px on every view, Waiting included (224 px before).
  • The start form shows on the list only.
  • Opening on #waiting lands on Waiting without taking focus, and Back goes from Graph to List.
  • On Settings, the notice and listen-address controls are visible. On the list they're absent, both before and after visiting Settings.
• Both page scripts pass node --check.

Not verified

• A real screen reader. Focus moving to the heading was checked with document.activeElement, not by listening.
• The narrow layout's new grid rows were only read, not measured in a narrow window.
• Browser notifications themselves ("Tell me when a run needs me") were reviewed and left as they are. They ask on click and say what was decided. This PR fixes the settings for where notices are sent, not the browser's own notifications.