I can help by answering most of your questions:
The output port and the test input port both contain "test inputs" (p. 1-44):
[...] I assume the bits contain the current state of each line, i.e., clock
Correct. You can confirm this from the block diagram in your referenced PDF (PDF page 60, marked 1-38). Somewhere I have a PC/AT schematic on paper, which shows the same answer, but in more detail.
But what are those "test inputs" at all? Why connect "test inputs," as
for testing during initialization or something, to clock and data lines?
The PC keyboard protocol in bidirectional, using open-collector drivers on both lines from the PC and from the keyboard. The PC (8042) needs to be able to read the current state of the lines, since they could be driven low by the keyboard, when the PC wants to send data to the keyboard. The most common situation is that the PC is receiving keyboard scan code data, coming into the 8042 via those input pins.
So in brief, the PC needs to be able to read (input) the current state of those signals, to test the signal state and also to receive keyboard data, as well as write (i.e. output / drive) the PC's desired state of those signals.
The same situation applies with the (slightly similar) I2C protocol - the I2C master device needs to be able to read the state of both signals and be able to drive them. (I'm skipping some detail here - more available if needed - readers who think the I2C master only needs to monitor the SDA line should read about clock-stretching.)
Also what do "(output)" and "(input)" mean?
In this context, output = output of 8042, which goes via appropriate open-collector driver chip to the keyboard connector; input = input to 8042 i.e. 8042 is reading the current state of the signal at the keyboard connector.
I can't quickly address the question about that specific command, but I would expect it to be used during POST, to confirm that the keyboard interface is working correctly i.e. PC drives each signal and confirms (via the test / input path) that each signal has changed state correctly.
Added: If someone is interfacing a PC keyboard to a non-PC device (e.g. embedded system) which isn't going to send any commands to the keyboard, then that simplifies what is needed to successfully control the interface. Above I have assumed you are asking about normal PC keyboard interface usage.
Added: Personally, I suspect that we should read "Test-Input Port" as "test and input port", since those signals perform both functions - input data from keyboard, and test current signal status.