6.67.1 - SWDiag aLead survives a seek, corrupt= rename

A patch for the software-decode diagnostic line, both halves from the AE#407 thread and gathered in AE#479. Nothing in the playback path changes; what changes is whether the [SWDiag] line tells the truth in the two places it did not.

The aLead after a seek is the post-seek queue, not the pre-seek one (AE#479)

aLead is the newest audio PTS the software pump has enqueued minus the clock, and the pump is the only writer of that marker. A seek flushes the audio queue on the main actor while the pump is still on the pre-seek generation. After a playing seek the pump republished its stale local once more before it noticed the seek; a seek that landed paused parked it in its pause wait, which checks neither the generation nor the box, so it wrote nothing until play(). Either way the line read old PTS minus re-anchored clock: aLead=475.49 on a backward scrub in the field log, -23.89 for five consecutive paused ticks on the harness (16.11 minus the 40.00 the clock had just been anchored at).

The seek path now clears the marker when it flushes, under the seek's generation, and the pump's writes carry the generation they were produced under, so a write from before the flush cannot put the flushed queue's PTS back. parkedPkts and rebuf are unchanged: they are the pump's own state and were never stale. Measured with the new aetherctl play --host-calls pauseseek drill (pause at t=12, seek at t=15 while paused, resume at t=20), which the existing drills could not stand in for: a --paused mount never fills the pump, and a --seek-every burst never pauses. Before: five ticks of aLead=-23.89. After: aLead=- until play(), then 4.01 on the first playing tick. The playing-seek burst (--seek-every 5 --seek-count 5 --seek-pattern 40,5) reads 4.00 on every first tick after a landing, as before.

corr= is corrupt= (AE#479)

The field is AVSampleBufferDisplayLayer.videoPerformanceMetrics.numberOfCorruptedFrames and nothing else. corr read as a correction count and was taken for one in the AE#407 thread, where a corr=0 was cited as evidence that no drift correction had run. There is no drift correction on that path, so the token carried no information about pacing; now it does not look like it does. Anyone grepping session logs for corr= needs the new spelling.

Both reported by @classicjazz, in the AE#407 field log.

Full changes: CHANGELOG.md, diff 6.67.0...6.67.1.