The pager opens one entry back out of the join

[torstei]

z renders every multi-line entry as one row, which is what makes ten stack
traces comparable at all — and the next thing after picking one out of the ten
is reading it. Z opens the entry under the cursor back into its own lines
while the other nine stay rows to come back to; pressing it again joins it,
from any of its lines, since what the reader is pointing at is the entry and
not the row.

  10:00:01 INFO started
  10:00:02 ERROR boom on req-7f3a ↵ at com.visena.Boom.frame0(Boom.java:40) ↵ …
> 10:00:03 ERROR boom on req-991c
          at com.visena.Boom.frame0(Boom.java:40)
          at com.visena.Boom.frame1(Boom.java:41)
          at com.visena.Boom.frame2(Boom.java:42)
  10:00:04 INFO after

Several can be open at once, because comparing two of them is what picking
them out was for. It is an exception to a rendering rather than a second
mode: an open entry is rendered from the source's OWN Line objects, so its
framing is the entry framing again — the entry motion steps over the whole
trace, the bold copy target covers it, and a bare c still takes all of it —
and z, which sets the whole screen, builds the join afresh and so clears the
exceptions.

⚠ An open entry is remembered by its ordinal, the nth entry of the source,
against this pager's habit of holding every position as an offset: an entry
still at a live edge has none, and every one of them reports 0, so a set of
offsets would open all of the live-edge entries together. An answer is a
closed set, so the nth entry stays the nth — and the tape, where the run does
renumber, has no multi-line entry to open in the first place.

The place-keeping z already did — the cursor and both ends of a region
travelling as offsets, the upper one widened to the end of the entry it lands
in — is now shared with Z (View._rerender) rather than written twice: the
rows renumber the same way under both, and a region that quietly became a
different set of lines is the copy that takes the wrong thing.

Tests

Four new ones in tests/timberview/test-timberview, and z/Z are driven
through Screen.step in one of them because a binding nothing exercises is one
a refactor can lose:

• opening one entry leaves the others as rows, keeps the cursor, and keeps the
  entry one entry to entry_span, c and the entry motion — closing works
  from a continuation line, and a one-line entry says there is nothing folded in
• it is a property of the join: refused with nothing joined, and cleared by a
  z round trip
• two live-edge entries (no offset, both reporting 0) open one at a time — the
  test the ordinal keying exists for
• a live region survives Z in both directions

71/71 timberview, 42/42 timbersh, 39/39 client.

Docs

? in the pager, timberview(1), the pager section of tools/README.md, and
a new Built: ten traces on one screen, and one of them opened section in
docs/plans/view.md.