Keccak padding implementation, and bit ordering
Both are correct, it is confusing because the summary page is discussing the state in terms of bytes, and the spec doc in terms of bits. The actual state for Keccak-1600 is built from 64-bit words.

During the transfer of the input message to the state, the bytes are essentially put into the words in reverse order, which now makes the summary page correct. This is related to the endianness of the specification and how the input message is placed into the state.

Here is an example of the first 576 bits of the input state of Keccak c=1024,r=576 AFTER padding for a simple message "test".

0000000174736574
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
8000000000000000


It can be seen that the 0x01 byte appended to the message precedes the message inside the first 64-bit word, and the final 0x80 byte occupies the highest bits of the final 64-bit word, exactly as how the 10*1 padding scheme says it should.

The resultant output digest after 24 rounds of permutation is:

1e2e9fc2002b002d75198b7503210c05a1baac4560916a3c6d93bcce3a50d7f00fd395bf1647b9abb8d1afcc9c76c289b0c9383ba386a956da4b38934417789e

I believe somewhere in the NIST submission document there is notation describing the bit/byte ordering, as NIST used a different bit ordering for the SHA-3 API.