List the changed files in the site's details as trees, each opening in the editor - #677

…e it leads

Fixes from the self-review of the previous commit (#669).

- "Choose application…" after a file would not open now opens that file in
the application picked. The notice keeps the file it was about.
- A file is judged by its real path as well as its name, so a symbolic link
in the site that leads out of it is refused. `existingSiteFile` in
editor-launch.js does this for both `editor:open` and `dir:show`, with
`realpath` injected. A site whose own folder is behind a link (macOS's
/var) still holds its files.
- `dir:show` logs a refused file, like `editor:open` does.
- `missing-file` is listed in `REVEAL_REASONS`, which is where `dir:show`
takes it from.

Refs #669

Found in a manual pass (#669): the paths read as plain text, and the
section sat below the processes.

- Each file has a file icon beside it, like the server's links, and is
drawn in the brand colour and underlined. A button drawn as a link gets
no underline from the browser the way an <a> does.
- The section comes first in the details while a change is applied,
above the facts about the checkout.

Refs #669

…n Windows

Fixes from the second self-review (#669).

- `existingSiteFile` returns `{ file, error }`. "Nothing there" stays
`missing-file`; any other realpath failure (a folder that cannot be read,
a loop of links) is `unreadable-file` with the system's code, said and
logged as itself rather than as a file the change may have deleted.
- The link check is tested for Windows from any machine: a junction to
another drive or out of the site is refused, and a site recorded with a
lower-case drive letter still holds its files.

Refs #669

Slice 2 of #669: what slice 1 does for an applied patch, for a pull
request checked out as its own branch.

- Checking out a pull request records, on its `pr/N` branch, the files it
changed: the list its preview showed, measured locally from the head the
branch was put at. Measured before the store is read, so nothing yields
between that read and the write (#172). A head that cannot be described
records no list rather than keeping an earlier head's.
- `site:status` hands the list on with the pull request, and "Affected
files" lists it while the pull request is checked out. One checked out
before this records nothing until it is checked out again.

Refs #669

Slice 3 of #669. The section becomes "Changed files", in two groups:

- "From the patch" / "From PR #N": the change's files, each marked "also
edited" when the contributor has changed it since. A patch's files are
fingerprinted when it is applied (src/change-fingerprint.cjs: SHA-256 of
the content, line endings normalised) and compared with the disk. A pull
request is its branch's base, so its files among the changes are edited.
A patch applied before this has no fingerprints and is not marked.
- "Your changes": every other file changed on the branch, "new" when
created. A ticket with nothing applied shows only this group.

`git:unsubmitted-work` returns each file's `added` and the
`editedSinceChange` list; no new channel. It now reads the branch's
record, so the test harness's `patchMain` gets an empty fake store.

Refs #669

Two findings from the review of the #669 stack:

- The contributor's file list stayed as it was after a discard, a ticket
switch, or an apply, revert or pull request switch, until the window
next regained focus. Each of those now clears the list and asks again.
A journey discards a new file and checks it leaves "Your changes"
without a refocus; the "list goes away" checks wait for no dialog to be
open, since a modal makes an absence check pass on its own.
- Moving a ticket onto trunk dropped the applied patch's text but kept
its fingerprints, so a file trunk changed could be marked "also
edited". The move now drops both.

Refs #669

From the re-review of the #669 stack: every exit from an apply cleared
"Your changes" and walked the tree again, including a patch that did not
fit and a pull request checkout refused before it started. Nothing was
written, so the list blinked out and back, moving the sidebar just as
the refusal appeared. The list is now dropped only when the apply, revert
or switch wrote; every exit still refreshes it.

A journey holds the walk after a refused patch and checks the
contributor's file is still listed. It fails without this.

Refs #669

A switch that fails part-way keeps the list until the next walk answers,
rather than clearing it. Said in the hook's comment, from the review of
the previous commit.

Refs #669

"Discard your changes" in the changes note and the review modal now
removes only the contributor's own work. The ticket goes back to its
base as before, and an applied patch is put back from its stored text.
A patch whose text was not kept goes too, and the question says so.
"Discard this ticket to its base" still removes the patch.

Part of #669.

- Fingerprint the patch again after putting it back, so a patch applied
  over earlier edits is not marked "also edited" afterwards.
- Move the edit count and the toast wording into changes-note.cjs.
- Disable "Discard your changes" when a kept patch or PR has none of
  the contributor's work on it.
- Add journeys for the escape hatch and the disabled link, and an
  ipc-wiring case for a checked-out pull request.
- Update comments that still named "Discard all changes".

Part of #669.

The new discard tests built their repository without core.autocrlf, so on
Windows the app's CRLF view wrote the files back with CRLF and the LF
assertions failed. They now use the shape the app's own clone has, as the
comment on adoptedRepo says byte-for-byte tests should.

…icons

Each file under "Your changes", and each patch or pull request file the
contributor edited, gets a revert button. The file ends as "Discard your
changes" would leave it: a file of the contributor's goes back to the
base or is deleted, a pull request's goes back to the pull request, and
a patch's goes back to the base with its part of the patch put back.
An untouched patch file, or one whose patch text was not kept, has none.

"also edited" and "new" become a pencil and a plus, named for screen
readers and explained in a tooltip.

Part of #669.

- Add revertFile to the packaged smoke test's preload keys.
- Refuse either end of a file the patch renames, and give neither a
  button: it goes back only with the whole patch.
- Decide a patch file by the same "edited" answer the list marks it by,
  so a file the contributor deleted or edited back to the base reverts.
- Give the held revert button its reason, as the discard link does, and
  make the marks focusable so a keyboard reaches their tooltips.
- Move the toast and the reply's wording into affected-files.cjs.
- Clear a revert's error when the list it was shown under goes.
- Say when a failed revert could not put the file back, and do not
  report a failure for a revert whose record write failed.
- Test the rollback, a file the patch created or deleted, renames, and
  the #172 guard.

Part of #669.

The new revert-file tests built their repository without core.autocrlf, so on
Windows the app's CRLF view wrote the files back with CRLF and the LF
assertions failed. They now use the shape the app's own clone has, as the
comment on adoptedRepo says byte-for-byte tests should.

The patch preview's path is now looked for in the dialog only: the file list in
the site's details names the same file once it is edited, which made the
locator match twice whenever the list refreshed first.

…in the details

Each group, the applied change's and the contributor's own, is a tree under
its heading. Each folder has a row of its own and starts open; its row's
button, or the left and right arrows, close and open it. A file is named by
its own name with the page icon and its path as its tooltip, since the folder
rows above it say where it is. Its pencil or plus stays after it, now the
name's description rather than a stop of its own, since only buttons are in
the tree's reach of the arrow keys; its revert button is in a cell of its own
at the end of the row, which Right reaches from the name. The section now
comes after the build watch, so a long list never pushes the server and the
watch out of reach.

Drawn with the design system's TreeGrid, which reads as a tree to a screen
reader and moves between rows with the arrow keys.

The file list was walked as soon as an apply, a revert or a pull request
switch changed the tree, but the status it is grouped by was read again only
once the install and the build were over. For those minutes a patch's files
were listed as the contributor's, a reverted patch's were still the patch's,
and a pull request left behind was still named. The status is now read with
the walk.

The tree remembers the last button focused in it and gives every other one no
tab stop, so a file that left the list on a refresh took the whole tree out of
the tab order with it. The tree is keyed by its files, so a new list is a new
tree; closing a folder is not a new list. The table is named for its group as
well as its wrapper.

…ther journeys do

A kept patch with no fingerprints marked none of its files as edited, so Discard your changes was disabled and no file could be reverted, leaving only the discard that removes the patch. Its files still changed now count as possibly edited, and reverting one no longer gives the record a list of that file alone.

…vert

The reverted file was still marked as edited, since it still differs from the base. It now gets its fingerprint, and the patch's other files one nothing matches, so they stay marked until reverted.

… files

A folder at the first level started on the details' edge, which clips, so its ring was cut off as the revert button's was.