[bengl]

Builds on #32, so its first commit is #32's. The second commit is this change.

What changed. flush({ signal }) takes an AbortSignal, such as AbortSignal.timeout(ms), the way Node core APIs take one. When it aborts, the promise rejects with an AbortError shaped like core's: code ABORT_ERR, message The operation was aborted, and the signal's reason as its cause. Core builds that error from an internal class, so microtel builds the same shape. Export failures still resolve the promise, so only an abort the caller asked for rejects.

Aborting stops the waiting, not the export. The export keeps running, bounded by exportTimeout, and its spans still reach the collector if it succeeds. With a signal that has already aborted, the promise rejects right away and no export starts, so the spans stay buffered for the next flush. The listener goes on through addAbortListener(), so it runs even when an earlier listener stops the event's propagation, as core's own abort listeners do. It comes off once the flush settles, so one signal can serve many flushes.

Validation. Options must be an object and signal an AbortSignal, checked the way core checks them. validateAbortSignal is ported from core into lib/validate.js, with parity tests against core's own. The beforeExit handler now calls flush() with no arguments, since Node passes it the exit code.

Not taken. A separate timeout option. AbortSignal.timeout() already covers it.

Tests. In test/test-flush-promise.js:

• no signal, and empty options, behave as before
• invalid options and an invalid signal throw ERR_INVALID_ARG_TYPE
• an already-aborted signal rejects and leaves the spans for a later flush, which exports them
• aborting while an export is in flight rejects right away, and the export still finishes. The collector holds its answer until after the rejection, so a flush that waited instead would deadlock the child. A flush started after the abort stays pending until the held export is answered.
• the flush still rejects when an earlier abort listener stops propagation
• AbortSignal.timeout() rejects with its TimeoutError as the cause
• the abort listener is gone once flush() settles