Fix custom mining job chain-tip transitions

[0xjc65eth]

Summary

Fixes ExtendedChannel::on_set_custom_mining_job so a custom mining job that moves the channel to a new chain tip transitions the previous active job into the stale set, flushes seen shares, and clears obsolete job-target mappings before registering the new active job.

The change is intentionally scoped to actual chain-tip transitions. If a custom job arrives for the same tip, the previous behavior of keeping the old job as a past job is preserved.

Closes #2157.

Why

on_set_new_prev_hash already performs this cleanup when the tip changes, but custom-work/JD flows can move the tip through SetCustomMiningJob instead. Without the cleanup, late shares for the previous block can be evaluated against the new chain tip and reported with the wrong validation error, while old job state continues to accumulate.

Testing

• cargo fmt --check
• git diff --check
• cargo test -p channels_sv2 --lib test_set_custom_mining_job_chain_tip_change_marks_past_job_stale
• cargo test -p channels_sv2 --lib

Seek the stale path; leave no ghost jobs behind.