fix(async): pooledMap surfaces errors thrown by the input iterable

[LeSingh1]

Fixes #6716.

When an async iterable passed to pooledMap throws (rather than a transformation), the catch block discarded the error and built an AggregateError populated solely from the executing transformations. With no transformation rejections in flight, callers saw only:

AggregateError: Cannot complete the mapping as an error was thrown from an item
    errors: []

The underlying cause was unrecoverable.

Repro from the issue:

import { pooledMap } from "jsr:@std/async/pool";

async function* errorThrowingIterator() {
  throw new Error("Iterator failed on first step!");
  yield 1;
}

const results = pooledMap(2, errorThrowingIterator(), async (i) => i * 2);
for await (const _ of results) {}
// AggregateError, errors: [] — the real cause is lost

After the patch the iterable's error rides through in AggregateError.errors:

message: Cannot complete the mapping as an error was thrown from an item
errors:  [ "Iterator failed on first step!" ]

Implementation: bind the catch's value as iterError and errors.push(iterError) only when it isn't already in errors. The Promise.race rejections from the executing pool are already surfaced via the existing allSettled walk, so the includes check prevents the common transformation-rejection path from duplicating its own reason.

Tests:

• New pooledMap() surfaces errors thrown by the input iterable (#6716) pins the iterable-throws case.
• The existing pooledMap() handles errors test (which exercises Promise.race rejections, not iterable throws) still produces exactly two rejections, confirming no double-counting.

All 6 pool_test.ts tests pass.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.57%. Comparing base (cdf74a8) to head (d5ee03f).
⚠️ Report is 18 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7169   +/-   ##
=======================================
  Coverage   94.57%   94.57%           
=======================================
  Files         636      636           
  Lines       52142    52143    +1     
  Branches     9401     9402    +1     
=======================================
+ Hits        49315    49316    +1     
  Misses       2249     2249           
  Partials      578      578           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bartlomieju]

Solid fix for a real silent-failure bug. The identity-based dedup is correct — in the transformation path Promise.race rejects with the same object that Promise.allSettled later surfaces, so includes suppresses the duplicate and the existing handles errors test still yields exactly two errors. All 6 tests pass locally.

Two small, non-blocking notes inline.

[bartlomieju]

Non-blocking edge case: includes dedups by ===. If the iterable throws a non-object primitive (e.g. a string or number) that happens to equal a transformation rejection reason already in errors, the iterable's error would be silently dropped. It's an extreme corner and the current behavior is reasonable, but worth a one-line comment noting the dedup is identity/value-based so the assumption is explicit.

[bartlomieju]

This transformation (Promise.resolve(i)) never rejects, so the test only exercises the pure iterable-throw path. Consider adding a combined case where the iterable throws while a transformation is also in flight and rejecting — that would lock in that both the iterable error and the transformation rejections appear together in AggregateError.errors, which is exactly the interaction the !errors.includes(iterError) guard governs. Optional, since this test plus the existing handles errors test cover the two paths individually.