fix(semantic): don't ICE when an impl provides an associated item of the wrong kind

[orizi]

Summary

When an impl provides an associated item with the wrong kind (e.g., a const where a type is expected, or a type where an impl is expected), the compiler previously panicked via extract_matches! instead of emitting a proper diagnostic. This PR replaces those panicking extract_matches! calls with try_extract_matches! in impl_type_by_trait_type, impl_constant_by_trait_constant, and impl_impl_by_trait_impl, so that a mismatched-kind item is treated as "not found" and a graceful skip_diagnostic error is returned instead.

A new test case is added covering cross-kind collisions where MyImpl provides a const AsType, type AsConst, and type AsImpl against a trait expecting a type AsType, const AsConst, and impl AsImpl, verifying that appropriate E2014 diagnostics are emitted for each mismatched item.

---

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 an impl supplies an associated item under the correct name but the wrong kind (e.g., a const instead of a type), the lookup functions assumed the item would always match the expected ImplItemId variant and called extract_matches!, which panics on a mismatch. This caused a compiler crash rather than a user-facing diagnostic.

---

What was the behavior or documentation before?

The compiler panicked when an impl item's name matched a trait item but the kinds differed (e.g., const Foo provided where type Foo was expected).

---

What is the behavior or documentation after?

The compiler now emits an E2014 diagnostic ("Impl item <kind> <name> is not a member of trait <trait>") for each cross-kind collision and continues compilation without crashing.

---

Related issue or discussion (if any)

None.

---

Additional context

The refactor also simplifies the lookup logic by chaining ?, and_then, and ok_or_else instead of nested match blocks.

[orizi]

• fix(semantic): don't ICE when an impl provides an associated item of the wrong kind #10206 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[reviewable-StarkWare]

This change is 

[cursor]

PR Summary

Low Risk
Small, localized change in impl–trait item resolution with clearer error handling and a new regression test; no auth or runtime behavior changes.

Overview
Fixes a compiler crash when an impl defines associated items under trait names but with the wrong item kind (e.g. const AsType where the trait expects type AsType).

In impl_type_by_trait_type, impl_constant_by_trait_constant, and impl_impl_by_trait_impl, lookups no longer use panicking extract_matches! on impl_item_by_name results. They use try_extract_matches! so a same-name, wrong-kind entry is treated as missing and returns skip_diagnostic instead of ICE-ing. Validation paths can still emit E2014 (ImplItemNotInTrait) for those mismatched items.

Adds a diagnostics test for cross-kind collisions (const/type/impl swapped) and expected follow-on errors when using those items in code.

^{Reviewed by Cursor Bugbot for commit 86292dc. Bugbot is set up for automated code reviews on this repo. Configure here.}