Fix updating the diskArray nextPipPageIdx when multiple new PIPs are added

[benjaminwinger]

Silly mistake on my part here, as I guess I made it unconditionally set the nextPipPageIdx on the updatedLastPIP when doing the pip caching optimization in #3189.

The test suite doesn't have any copies large enough to trigger this, as we only add multiple PIPs in a single transaction when copying 1023 * 16 slots (num AP indexes per pip index page times the number of slots per page), or roughly 58 million primary keys (divided among 256 indexes with 14 entries per slot for an int64 slot).

This should be reproduce-able on the second copy, but won't encounter a failure without doing look-ups on certain keys or doing a third copy.
I'll add a larger copy test in a future PR once the performance has improved a little more, as the multi copy test is already very slow in debug mode.