)

The "return the last array entry's error" branch in
`package_target_resolve` was dead code: `i` comes from `enumerate()`, so
`i == targets.len()` could never be true. Errors from array entries were
always swallowed like `undefined`, so an invalid target in the last
fallback entry surfaced as a generic `PackagePathNotExported` instead of
the specific error — despite the comment right below claiming "Return or
throw the last fallback resolution null return or error".

This fixes the off-by-one (`i + 1 == targets.len()`) so the last entry's
error now propagates, matching the documented intent and Node's
`lastException` behavior for arrays.

One deliberate exemption: `ResolveError::NotFound` still falls through.
It only arises from re-resolving a bare `imports` target (e.g. `\"#a\":
[{\"import\": [\"#b/import.js\"]}]`) through the module system, and
enhanced-resolve treats an unresolvable candidate there as a soft
failure, not a hard error — the ported "Direct and conditional mapping
#4" test pins that behavior. Node would actually throw immediately on
any non-`ERR_INVALID_PACKAGE_TARGET` error inside the array loop, which
is stricter than enhanced-resolve; the exemption keeps us compatible
with the latter.

Adds two imports-field tests: an invalid target in the **last** array
entry now errors (previously `Ok(None)`), and an invalid target in a
**non-last** entry still falls through to the next entry.

Split out of #1263.