It turns out the odd "different CAN files have different header offsets"
came from the fact that the decode block was different lengths, and I
had not picked the correct place to start - and instead had found two
different places that were at different offsets due to the decode block
length differences.
This fixes that up, and it looks like the dive header is correctly
descrambled (but what the data *means* is unclear, although there is now
an ASCII date and time visible, so at least one part of it is pretty
obvious).
The actual dive data unscrambling is still different for the two
test-files I have to play with, I do not know why.