fix(sdk-typescript): distinguish cancellation from timeout

[AaronZ345]

Description

The TypeScript SDK currently maps two different events to the same error:

• the SDK's request timer expires;
• the caller explicitly aborts through AbortSignal.

Both become DEADLINE_EXCEEDED, so callers cannot tell whether a request timed out or was intentionally cancelled. Retry code may then retry work the application deliberately stopped.

This change records which source aborted the internal controller. Timer expiry remains DEADLINE_EXCEEDED; caller cancellation now returns the standard OpenViking ABORTED code.

Human Involvement

• A human participated in the implementation or review loop
• This PR was generated entirely by AI agents without human participation in the loop

Related Issue

No linked issue.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that causes existing functionality not to work as expected)
• Documentation update
• Refactoring (no functional changes)
• Performance improvement
• Test update

Changes Made

• Track whether the caller or the timeout aborted the internal request controller.
• Preserve DEADLINE_EXCEEDED and a timeout-specific message for timer expiry.
• Return ABORTED for both pre-aborted signals and cancellation while a request is in flight.
• Prevent a later timeout callback from overwriting an earlier caller cancellation.

Testing

• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• I have tested this on the following platforms:
  • Linux
  • macOS
  • Windows

Commands run from sdk/typescript:

• npm test — 30 passed
• npm run typecheck — passed
• npm run format:check — passed
• git diff --check — passed

Checklist

• My code follows the project's coding style
• I have performed a self-review of the code
• I have commented the code where needed
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• Any dependent changes have been merged and published

Screenshots

Not applicable.

Additional Notes

No request API changes are required. Existing callers still pass an ordinary AbortSignal; only the resulting error code is corrected.