list-envelope discovery gives pub(super) and pub(in …) functions the key of the previous function #971

Summary

The registry-free list-cut discovery does not recognize functions declared pub(super) fn or pub(in …) fn. It assigns each cut in such a function to the previous fn it does recognize. The enclosing_item key can then name the wrong function.

Where

Checked on main at 8876c44.

• crates/aft/tests/list_envelope_conformance/support.rs, extract_item_name: the prefix list has pub(crate) fn, pub fn, fn and the async forms. It does not have pub(super) fn or pub(in …) fn. enclosing_item then walks back to the nearest recognized item.
• crates/aft/tests/list_envelope_drift_guard.rs, extract_item_name: the same prefix set.

Sites with the wrong key today

The first one is visible in list_surfaces.rs:1028-1031: the exclusion entry has enclosing_item: "files_with_hits", but its location_or_primitive names external_exact::sweep.

Reproduction

I wrote a script that copies the scanner's prefix rule. It compares that rule with a rule that also accepts pub(super) and pub(in …) . Over the 324 cut sites it checks, it gives these four differences. All other keys are the same.

Effect

• An exclusion or surface entry must use a key that does not agree with the code. A reader cannot match the entry to its function.
• If the real function moves or is renamed, the key does not change. If the wrong function is renamed, a registered cut appears as unregistered.

Suggested fix

Accept any pub(...) visibility before fn, const, static, struct and enum in both extract_item_name functions (for example, strip a leading pub( … ) group before the prefix match). Then change the key of the external_exact.rs exclusion to sweep, and the keys of any registered entries for the other three sites.