fix(core): keep crawler enqueue limits when options carry explicit undefined

[B4nan]

Follow-up to #3924, same bug class one level down.

BasicCrawler's context-bound enqueueLinks built its call as { requestQueue, robotsTxtFile, respectRobotsTxtFile, onSkippedRequest, limit, ...options }, so a user options object carrying an explicitly present undefined key silently discarded the computed value:

await enqueueLinks({ urls, limit: config.limit }); // config.limit is not set

Neither ow.optional.number nor TypeScript (without exactOptionalPropertyTypes) rejects an explicit undefined, so the calculateEnqueuedRequestLimit() result was dropped — the queue kept growing past the remaining maxRequestsPerCrawl budget and the enqueueLimit skips were never reported to onSkippedRequest. maxRequestsPerCrawl is still enforced as a stop condition via isMaxPagesExceeded(), so the effect was queue bloat and missing reporting rather than an unbounded crawl. The same applied to robotsTxtFile and respectRobotsTxtFile (robots.txt filtering silently disabled at enqueue time), and to requestQueue, where the explicit undefined made ow throw instead.

Unlike #3924 this isn't a pure reordering, so the semantics for each computed key:

• limit — now min(user limit, remaining maxRequestsPerCrawl budget). This is what addRequests() (maxNewRequests after the spread) and the per-crawler *CrawlerEnqueueLinks helpers have always done; this path was the outlier. A user limit larger than the remaining budget is now capped, which is a user-visible change.
• onSkippedRequest — composed instead of replaced: the crawler's reporting (logging, crawler-level onSkippedRequest) runs, then the user's callback. Previously passing a callback to enqueueLinks silently disabled the crawler-level one.
• requestQueue, robotsTxtFile, respectRobotsTxtFile — ?? fallbacks, so a defined user value still wins.

The enqueue-limit log message now also distinguishes the two causes, instead of blaming the user's limit when the maxRequestsPerCrawl clamp is what bit.

Not covered here: JSDOMCrawler and LinkeDOMCrawler never route context.enqueueLinks through this wrapper at all (they call the standalone enqueueLinks() directly, unlike CheerioCrawler/BrowserCrawler which forward the bound context function), so crawlDepth injection and maxCrawlDepth are inert there. Separate issue, separate fix.

[barjin]

lgtm, thank you @B4nan !

I just have one nit regarding the new changes ⬇️