`restrictions`: resolution of packages that have `exports` fields does not fall back correctly

rspack-resolver seems to have the same bug in restrictions handling that enhanced-resolve fixed here: https://github.com/webpack/enhanced-resolve/pull/600. (An error is returned when attempting to resolve a package that has an exports field defined, instead of falling back to resolve from a subsequent entry in modules configuration.)

The case is the one described here: https://github.com/orgs/webpack/discussions/21080, where "modules" is configured as an array of two or more entries, and "restrictions" is defined in a way that means the first "modules" entry will produce a resolution that does not meet the restriction.

I do not know Rust, so ignore this is if it's not a helpful illustration, but here is a Claude-generated repro (porting the new test cases enhanced-resolve introduced for this issue, and highlighting the scenario that fails): https://github.com/bregenspan/rspack-resolver/commit/abaf51a5eeeca1c5ff029fbd270a6b632c959567

Start with the enhanced-resolve PR #600 and the linked repro commit, then trace rspack-resolver's restrictions handling for packages with exports and multiple modules entries. Add a regression test for the fallback scenario and verify that resolution proceeds to a later modules entry when the first result violates the restriction.