Out-of-alphabetical-order label entry

The "extensions: stepfun" block is inserted between "extensions: deepseek" and "extensions: anthropic", which breaks the alphabetical ordering of the extension label section (D → S → A). stepfun should appear after sglang/signal and before telegram in the sorted block.

This is a comment left during a code review.
Path: .github/labeler.yml
Line: 249-252

Comment:
**Out-of-alphabetical-order label entry**

The `"extensions: stepfun"` block is inserted between `"extensions: deepseek"` and `"extensions: anthropic"`, which breaks the alphabetical ordering of the extension label section (D → S → A). `stepfun` should appear after `sglang`/`signal` and before `telegram` in the sorted block.

How can I resolve this? If you propose a fix, please make it concise.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

Two assertions, one call — potentially misleading structure

queueDeliveryFailureSystemEvent calls core.system.enqueueSystemEvent exactly once, producing a single joined sentence. Both toHaveBeenCalledWith matchers here match that same call because the full message contains both substrings. The two-assertion pattern looks as if two separate calls are expected, which could confuse future maintainers.

Consider adding toHaveBeenCalledTimes(1) alongside the existing assertions to make the single-call expectation explicit, and collapse the substring checks into one matcher to remove any ambiguity about how many times enqueueSystemEvent fires per failure batch.

This is a comment left during a code review.
Path: extensions/msteams/src/reply-dispatcher.test.ts
Line: 239-249

Comment:
**Two assertions, one call — potentially misleading structure**

`queueDeliveryFailureSystemEvent` calls `core.system.enqueueSystemEvent` exactly once, producing a single joined sentence. Both `toHaveBeenCalledWith` matchers here match that same call because the full message contains both substrings. The two-assertion pattern looks as if two separate calls are expected, which could confuse future maintainers.

Consider adding `toHaveBeenCalledTimes(1)` alongside the existing assertions to make the single-call expectation explicit, and collapse the substring checks into one matcher to remove any ambiguity about how many times `enqueueSystemEvent` fires per failure batch.

How can I resolve this? If you propose a fix, please make it concise.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

The PR title/description focus on the MSTeams delivery-failure system event, but this change set also adds the bundled StepFun provider plugin (plus docs + changelog). Please either update the PR title/description to reflect both changes, or split StepFun into a separate PR to keep review scope and release notes aligned.

This test passes env: { ...process.env, STEPFUN_API_KEY: ... }, which can accidentally include other provider API keys from the developer/CI environment and make the implicit-provider resolution nondeterministic. Prefer passing a minimal env object (or using the existing test harness helpers that snapshot/unset implicit env vars) so the test is isolated and stable.

Same issue here: spreading process.env into the env passed to resolveImplicitProvidersForTest can pull in unrelated provider keys and make the baseUrl/region assertions flaky. Pass only the env vars needed for this test case (or explicitly unset the implicit-provider env allowlist first).

Make inferred StepFun auth default to global endpoint

Placing standard-api-key-cn first makes non-interactive auth inference pick the China flow when users pass only --stepfun-api-key (no --auth-choice). resolveManifestProviderOnboardAuthFlags de-dupes shared flags by keeping the first matching choice, and inferAuthChoiceFromFlags then uses that first match, so the default becomes stepfun-standard-api-key-cn. For global users this writes .com endpoints by default and causes model calls to fail with global keys; ordering the global choice first avoids that regression.

Useful? React with 👍 / 👎.