Fix #2406, #2435: qualified requests no longer pick up stacked parameters

[ChristophyBarth]

Problem

A get(named(...)) could be satisfied by a same-typed value sitting on the scope's
parameter stack, shadowing the qualified definition. So passing parametersOf("event-id")
to one dependency could bleed that String into an unrelated @Named String further down
the graph (#2435), and checkKoinModules handed get(named("env")) the MockParameter
default "" instead of the named single (#2406).

Cause

In CoreResolverV2, resolution tries the parameter stack before the registry. Parameters
match by type only and carry no qualifier, so a qualified request would match whatever
same-typed value was on the stack.

Fix

resolveFromStackedParameters now returns null when the request has a qualifier, letting
it fall through to the registry. This mirrors the rule already used by
resolveFromScopeSource.

Behavioral change

Qualified resolutions could previously return a stacked parameter of the matching type;
they now always resolve from definitions. Unqualified resolution, including the #2387
stacked-parameter path, is unchanged.

Tests

Added cases in ParametersInjectionTest (root, scope, and linked-scope variants) and
CheckModulesTest. Verified on JVM, wasmJs, and native.

Closes #2406
Closes #2435

[ChristophyBarth]

Closing — this was fixed independently on main by 4fae618 (#2370/#2408), which makes the identical change in CoreResolverV2. I'll open a small follow-up PR with the docs note and the checkmodules-path test coverage that aren't on main yet.