fix: auto-resolve wontfix clippy/cargo items absent after cfg(test) filtering

[fluffypony]

Summary

• When inline cfg(test) filtering was introduced (by me), clippy and cargo diagnostics originating from test-only modules are now correctly excluded from scans. This left behind stale wontfix issues from those detectors that would never reappear - but weren't being cleaned up either.
• This change auto-resolves wontfix items from clippy_warning and cargo_error detectors when they're absent from a scan, since the original wontfix decision is now obsolete (the filter handles it).

[peteromallet]

Thanks for looking into this @fluffypony! After reviewing, we've decided not to merge this one. The core concern — hardcoding Rust-specific detector names (clippy_warning, cargo_error) in the shared merge_issues.py engine module — would break the language/engine separation. Additionally, converting wontfix → auto_resolved would change reopening behavior: if the diagnostic reappears for any reason, it'd be silently reopened, overriding the user's manual disposition.

The existing _mark_scan_verified() handling preserves the wontfix status while recording that the item is still absent from scans, which we believe is the right behavior for manually-dispositioned items.

That said, if there's a specific scenario where wontfix clippy items are causing confusion for users, we'd love to hear about it — there may be a more targeted solution. Thanks for taking the time to dig into this!