Collection-run classification for aborted requests: failure, skip, or retry?

Context

Postman applies a global request-timeout default that can be overridden per request. Both the user-initiated Cancel button and a timeout expiration surface as error states in the Tests tab rather than as normal responses. Scripts can detect the absence of a response code and inspect error messaging, but the exact error shape is not part of a stable contract and varies across desktop, web, and CLI clients.

Constraint

A collection run with retry enabled must decide how to record each aborted request in the aggregate summary. The runner can treat the abort as a failure (incrementing the failure count), as a skipped item (excluding it from pass/fail totals), or as a candidate for retry (re-issuing the request up to the configured retry limit). The choice influences dashboard metrics, CI gate decisions, and downstream workflow triggers.

Uncertainty

Documentation does not specify a default classification, and the behavior appears to differ between manual runs and scheduled runs via the CLI. Error-object structure for cancelled versus timed-out requests is implementation-dependent, so any script-based classification is fragile across versions.

Questions

1. What is the current default classification for a cancelled request versus a timed-out request in a collection run with retries enabled?
2. Can the classification be configured per collection or per request without modifying the request script?
3. Does the CLI runner expose a flag to override the default classification for aborted requests?