fix(node-loader): short-circuit http(s) resolves and handle empty parentURL

[beldevem]

Fixes #77

Problem

resolve() in src/scripts/node-loader.ts didn't short-circuit for absolute http(s) URLs the way load() already does, causing two real-world failures when a native-federation host loads a remote over http(s) in a Node SSR process (module.register()-based loader hooks):

1. A relative specifier that is a sibling chunk of an already-loaded remote bundle (e.g. ./chunk-abc.js imported from https://remote-host/remote/entry.js) isn't in the import map, so resolve() fell through to nextResolve() which only understands file:/data:/node: specifiers and threw ERR_INVALID_URL.
2. context.parentURL can arrive as an empty string (not undefined) under module.register()'s worker-thread hook execution. resolveSpecifier()'s parentURL ? ... : baseURL check treated the empty string as falsy and silently fell back to the local baseURL instead of the remote's base, breaking both relative sibling-chunk resolution and import-map scope matching for that remote.

Fix

• resolve() now short-circuits for absolute http(s) URLs whether mapped via the import map, resolved as a relative sibling-chunk specifier, or already absolute mirroring the short-circuit load() already does.
• load() now records the last remote base URL it fetched (lastRemoteBaseURL); resolve() falls back to it when context.parentURL is empty, so relative sibling-chunk imports and scope matching keep working even when the parent URL is lost.
• load() now also returns responseURL for http(s) modules.

Tests

Added coverage in node-loader.spec.ts for the previously-untested scenarios: a mapped http(s) specifier short-circuiting instead of hitting nextResolve, a relative sibling-chunk specifier resolving via the URL algorithm, and the empty-parentURL fallback to the last loaded remote base. Updated the two existing load() tests to account for the new responseURL field. All 25 tests pass; node-loader.ts itself has zero TypeScript/lint errors.

Related: native-federation/angular-adapter#132 (filed against the wrong repo before the actual bug source was traced here).