sstable: audit external iter synthetic seqno assignment to range keys

Currently when constructing a merging/layered external SST iterator, we pass [][]sst to represent spans of layers, with non-overlapping spans in each layer and high layers shadowing lower layers. Internally this multi-iterator stack assigns authentic sequence numbers base on the layers, starting with [`seqNum = num_files`](seqNum += len(readers)) for the first file and [then decrementing it](https://github.com/cockroachdb/pebble/blob/e494c5548be077ff460984ca644d510dade91a0d/external_iterator.go#L179) for each file.

However that while that decrement is done after the synthetic sequence number option for the _point key_ iterator for that file has been initialized, it is done _before_ the range key iterator's synthetic seqno for that file has read it, meaning the range keys for a given file have a lower synthetic seqno than the point keys, and the last file will have zero/no synthetic seqno for its range keys vs 1 for its point keys.

Is this intentional? If so, some commentary in the code as to why it differs for the point vs range keys could be useful to future readers.

Jira issue: PEBBLE-1293