Fix short-circuit test when seeking in short files

When a file is very, very short (i.e., only one packet) and uses
 end-trimming, the apparent granule position preceding the first
 sample in the first packet can underflow.
We were computing this value by subtracting the packet duration
 from the computed per-packet granule position and expecting this
 computation to always succeed.
Because it could fail in the presence of end-trimming on the first
 packet (ironically, exactly the situation where the short-circuit
 is helpful), it would leave the value uninitialized, and then use
 it in a comparison, which is undefined behavior.
The correct solution is to check for failure and force the previous
 page's granule position to 0 in this case.
3 jobs for master in 1 minute and 26 seconds (queued for 2 seconds)
latest
Status Job ID Name Coverage
  Build
passed #10871
docker
autotools

00:01:26

passed #10873
docker
doc

00:00:17

passed #10872
docker
makefile

00:00:50