sl0ppty: a reply is never a request

`hello` was answered with the verb `hello`. Any pane that echoes what it is
sent -- `cat`, `tee`, a shell with echo on, a REPL waiting for a line --
therefore answered the answer, and the session answered that. Measured
before the fix: a pane running `tee` was sent 4,303,832 bytes and 165,532
hellos in a second and a half. Afterwards, 32 bytes and one.

The fix is the rule rather than the instance: every message the session
sends *to* a program ends its verb in `-reply`, no request verb may, and
`on_osc5577` drops one on sight instead of relying on no handler happening
to exist. So this cannot come back when the next verb gets an answer --
which is the commit after this one, and how I found it.

`hello`'s reply is now `hello-reply;sl0ppty;1`. That is our own extension
to the fork's protocol, not one of the five compatible verbs, so nothing
written against sl0ppi notices. The fork's `click` goes to a program too
and keeps its name: it predates the rule and is safe for the weaker reason
that nothing answers a click.

The suite was hiding this. `emit()` builds its pane out of `cat -v`, so the
existing `hello` test had a pane trading megabytes with the session while
it asserted -- and passed, because the assertion was `in`, and the first
reply was in there along with all the rest. It now counts.

Carries `pane_touch`, two lines, unused until the next commit: a pane whose
shaders changed has to be repainted, and nothing about its cells changed to
say so.

0 files changed, 0 insertions, 0 deletions