bugfix(semantic): Fixed suggested crate:: context paths. - #10044

Summary

Fixes a bug where the crate:: path prefix was incorrectly double-encoding the crate name. When resolving a path via the crate root, the crate name was being included in path_items in addition to the ViaCrate kind prefix, resulting in paths like crate::my_crate::module::Item instead of the correct crate::module::Item. The fix removes the crate name from path_items before constructing the ItemAccessInfo when the owning crate matches the context module's crate.

A regression test was added to verify that ambiguous method call diagnostics using crate:: paths display the correct path format (e.g., crate::provider1::T::foo rather than a double-encoded variant).

Type of change

Please check one:

• Bug fix (fixes incorrect behavior)
• New feature
• Performance improvement
• Documentation change with concrete technical impact
• Style, wording, formatting, or typo-only change

Why is this change needed?

When two traits were imported via use crate::provider::* glob imports and an ambiguous method call occurred, the diagnostic message was generating malformed paths that included the crate name twice — once from path_items and once implicitly from the ViaCrate kind prefix.

What was the behavior or documentation before?

Ambiguous method call diagnostics for items resolved via crate:: would produce incorrectly formed paths, including the crate name redundantly alongside the crate:: prefix.

What is the behavior or documentation after?

Ambiguous method call diagnostics correctly display paths in the form crate::provider1::T::foo and crate::provider2::T::foo, without duplicating the crate name.

Related issue or discussion (if any)

None specified.

Additional context

None.