v3.25.1

• Aborted provider calls fail over again on Node 24 (#85). Node 24's DOMException — including the AbortError thrown when AbortSignal.timeout fires or a call is cancelled — exposes message as a read-only getter, and two places assigned to it directly: the failover loop in analyze() while contextualizing a provider failure, and runCommand() while redacting secrets from the explained error. The assignment threw Cannot set property message of #<AbortError> which has only a getter, replacing the abort with a hard crash, so a timed-out provider took the whole read down instead of falling through to the next provider in the chain. On dsh this surfaced as "the vision engine failed" for any paste slow enough to hit the timeout. Both sites now write through one helper that assigns when it can and redefines the property on the same object when the getter refuses, so the error keeps its identity (instanceof, quota classification) and failover proceeds. Regression tests cover a real DOMException('AbortError') and both call paths. Thanks to @Dialong for a report that had already located both assignments and the fix.
• dsh: wrapper-forwarded streams say who forwarded them (#89). A (modlens vision) route forwards the converted call back through llm.stream, which emits a second llm/stream event carrying the same usage under the upstream provider id — so chain-tail meters counted the call twice, and their (turn, step) dedupe was defeated by the differing provider ids. The forwarded options now carry via: <wrapperProviderId> (deepseek-modlens or modlens-<upstream>), making the contract explicit: a downstream listener that sees options.via is looking at the wrapper's forwarded hop and should account only the upstream stream. The key stays in-process — dsh applies no runtime schema to stream options, and adapters serialize only known fields into the HTTP request. Meters matching the modlens-* name prefix keep working; reading via is the supported spelling from here on. Thanks to @lucas-wang-1 for the design note.