Run orphan-reasoning downgrade for all OpenAI responses runs

downgradeOpenAIReasoningBlocks is now gated on signatureIncompatible, so same-provider/same-API sessions skip this sanitizer entirely. That re-allows orphan OpenAI reasoning signatures (e.g. a trailing thinkingSignature JSON item without a following content item) to pass through unchanged, which can still trigger OpenAI Responses 400 transcript errors even when no cross-provider switch happened. This path was previously always sanitized for openai-responses/openai-codex-responses, so the new condition reintroduces a failure mode in normal same-provider continuations.

Useful? React with 👍 / 👎.

Pass runId into tool wrapper construction

This createOpenClawCodingTools call no longer forwards runId, so before_tool_call wrapping falls back to tool-call-id-only scoping (buildAdjustedParamsKey), which defeats per-run isolation when toolCallIds collide and drops run correlation data from hook payloads. The codebase already has explicit handling for runId-scoped collisions, so omitting it here can mix adjusted params across concurrent runs and make hook-driven auditing/debugging unreliable.

Useful? React with 👍 / 👎.

Preserve trigger and channelId in plugin hook context

The hook context built for model-resolution no longer includes trigger or channelId, even though PluginHookAgentContext defines them for hook consumers. Plugins that choose provider/model behavior based on run source (cron/heartbeat/user) or channel now always receive undefined in this phase, which silently regresses existing hook logic for embedded runs; the same omission also appears in the prompt-build hook context path.

Useful? React with 👍 / 👎.

downgradeOpenAIReasoningBlocks is now effectively unreachable

downgradeOpenAIReasoningBlocks is only called when signatureIncompatible is true. However, when signatureIncompatible is true, needsThinkingDowngrade is also true, so downgradeThinkingBlocksOnModelSwitch has already converted every signed thinking block (including OpenAI rs_*-signed ones) into plain text blocks. By the time downgradeOpenAIReasoningBlocks runs, there are no thinking blocks with OpenAI reasoning signatures left — making the call a no-op.

Before this PR, downgradeOpenAIReasoningBlocks was called unconditionally for every openai-responses session:

// Before (always ran for openai-responses):
const sanitizedOpenAI = isOpenAIResponsesApi
  ? downgradeOpenAIFunctionCallReasoningPairs(
      downgradeOpenAIReasoningBlocks(sanitizedCompactionUsage),
    )
  : sanitizedCompactionUsage;

Its purpose was to drop orphaned rs_*-signed reasoning blocks that trail an assistant turn with no following text item — a condition the OpenAI Responses API rejects with a 400 error. That cleanup now never happens for same-provider OpenAI sessions (the common case), re-introducing the exact class of 400 errors this PR sets out to fix.

The fix is to call downgradeOpenAIReasoningBlocks unconditionally for isOpenAIResponsesApi, independent of the cross-provider signatureIncompatible flag:

  const sanitizedOpenAI = isOpenAIResponsesApi
    ? downgradeOpenAIFunctionCallReasoningPairs(
        downgradeOpenAIReasoningBlocks(
          signatureIncompatible
            ? sanitizedModelSwitch
            : sanitizedModelSwitch,   // <-- always pass through downgrade
        ),
      )
    : sanitizedModelSwitch;

Or more simply:

  const sanitizedOpenAI = isOpenAIResponsesApi
    ? downgradeOpenAIFunctionCallReasoningPairs(
        downgradeOpenAIReasoningBlocks(sanitizedModelSwitch),
      )
    : sanitizedModelSwitch;

This is a comment left during a code review.
Path: src/agents/pi-embedded-runner/google.ts
Line: 498-504

Comment:
**`downgradeOpenAIReasoningBlocks` is now effectively unreachable**

`downgradeOpenAIReasoningBlocks` is only called when `signatureIncompatible` is `true`. However, when `signatureIncompatible` is `true`, `needsThinkingDowngrade` is also `true`, so `downgradeThinkingBlocksOnModelSwitch` has *already* converted every signed thinking block (including OpenAI `rs_*`-signed ones) into plain text blocks. By the time `downgradeOpenAIReasoningBlocks` runs, there are no thinking blocks with OpenAI reasoning signatures left — making the call a no-op.

Before this PR, `downgradeOpenAIReasoningBlocks` was called **unconditionally** for every `openai-responses` session:

```typescript
// Before (always ran for openai-responses):
const sanitizedOpenAI = isOpenAIResponsesApi
  ? downgradeOpenAIFunctionCallReasoningPairs(
      downgradeOpenAIReasoningBlocks(sanitizedCompactionUsage),
    )
  : sanitizedCompactionUsage;
```

Its purpose was to drop orphaned `rs_*`-signed reasoning blocks that trail an assistant turn with no following text item — a condition the OpenAI Responses API rejects with a 400 error. That cleanup now never happens for **same-provider OpenAI sessions** (the common case), re-introducing the exact class of 400 errors this PR sets out to fix.

The fix is to call `downgradeOpenAIReasoningBlocks` unconditionally for `isOpenAIResponsesApi`, independent of the cross-provider `signatureIncompatible` flag:

```
  const sanitizedOpenAI = isOpenAIResponsesApi
    ? downgradeOpenAIFunctionCallReasoningPairs(
        downgradeOpenAIReasoningBlocks(
          signatureIncompatible
            ? sanitizedModelSwitch
            : sanitizedModelSwitch,   // <-- always pass through downgrade
        ),
      )
    : sanitizedModelSwitch;
```

Or more simply:
```typescript
  const sanitizedOpenAI = isOpenAIResponsesApi
    ? downgradeOpenAIFunctionCallReasoningPairs(
        downgradeOpenAIReasoningBlocks(sanitizedModelSwitch),
      )
    : sanitizedModelSwitch;
```

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

Use project logger instead of console.warn

Both stripInvalidThinkingSignatures and downgradeThinkingBlocksOnModelSwitch use console.warn directly, while the rest of the codebase uses the structured log module (imported from ./logger.js). console.warn bypasses any log-level filtering, structured-logging sinks, or log routing the project relies on.

Consider importing and using log.warn(...) to match the surrounding code's logging conventions. The same applies to the identical console.warn call at line 406–410 in downgradeThinkingBlocksOnModelSwitch.

This is a comment left during a code review.
Path: src/agents/pi-embedded-helpers/openai.ts
Line: 322-326

Comment:
**Use project logger instead of `console.warn`**

Both `stripInvalidThinkingSignatures` and `downgradeThinkingBlocksOnModelSwitch` use `console.warn` directly, while the rest of the codebase uses the structured `log` module (imported from `./logger.js`). `console.warn` bypasses any log-level filtering, structured-logging sinks, or log routing the project relies on.

Consider importing and using `log.warn(...)` to match the surrounding code's logging conventions. The same applies to the identical `console.warn` call at line 406–410 in `downgradeThinkingBlocksOnModelSwitch`.

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

Pass observed overflow token count into compaction

Overflow recovery no longer extracts/passes the provider-reported token count into compaction; this call now omits currentTokenCount, so compaction loses the precise over-budget signal from errors like “277403 > 200000”. In that scenario compaction can under-trim and immediately re-overflow, turning a recoverable retry into a terminal context_overflow.

Useful? React with 👍 / 👎.

Emit end_turn stopReason for sessions_yield completions

This now reports stopReason only for clientToolCall and drops the previous yieldDetected -> "end_turn" mapping. sessions_yield sets yieldDetected (not clientToolCall), so successful yield exits now surface stopReason: undefined, which breaks lifecycle consumers that rely on end_turn to treat the parent run as cleanly finished and idle.

Useful? React with 👍 / 👎.

Use async model resolution to run dynamic model prep hooks

Switching this call from resolveModelAsync to resolveModel skips provider prepareDynamicModel hooks (implemented in the async resolver path), so providers that require async priming before dynamic model resolution (for example OpenRouter capability preload) now run with stale/default model metadata. That can mis-size context budgets and feature flags on first use, leading to incorrect runtime behavior.

Useful? React with 👍 / 👎.