No keydown/keyup for autorepeats; no keypress except for autorepeats

Nobody has claimed this yet.

InputEvent.Keyboard emits `keydown`, `keyup`, and `keypress` events. This looks like the browser keyboard event api. But it behaves differently.

In browser, a physical depress and release gives a keydown-keypress pair, and then a keyup. A keyboard autorepeat gives just a keydown-keypress pair (it used to give a keyup as well).

EV_KEY is different. Value 1 is physical depress. Value 0 is physical release. Value 2 is autorepeat.

These EV_KEYs are currently emitted as `keydown`, `keyup`, and `keypress`. So you don't get `keydown` (or `keyup`) from autorepeats. And you don't get a `keypress` from any physical key depresses, only from autorepeats.

So while this looks like the browser api, it behaves differently. Which is confusing.

Some possibilities include: (a) document that you don't get `keydown` for autorepeats, and don't get `keypress` for physical presses; (b) rename `keypress` to `repeat`; (c) rename `keyup` and `keydown` to `depress` and `release`. (Or to `keyrepeat`, `keydepress`, `keyrelease`?)

Thanks for your work!

Start with InputEvent.Keyboard and trace how EV_KEY values 0, 1, and 2 become keyboard events. Review the browser behavior described in the issue and determine which event naming or documentation approach is appropriate. Done means the event semantics are decided and implemented or documented consistently.

Written by the indexing model from the issue text.