interrupt() during CLI startup resolves successfully but does not interrupt (0.3.241)

## Summary

An `interrupt()` that lands before the CLI has emitted `system/init` does nothing — the turn runs to completion — but resolves with the same receipt a real interrupt does. The resolution itself carries no signal: the caller can only infer the no-op after the fact, once the turn completes normally, which is too late to retry or to tell the user their stop request was dropped.

## Environment

- `@anthropic-ai/claude-agent-sdk` 0.3.241, vendored CLI 2.1.241
- Node v24.13.0, macOS (arm64), streaming input mode, subscription auth

## Repro

Runnable as-is from a project that has the SDK installed:

```js
import { query } from '@anthropic-ai/claude-agent-sdk';

const keepOpen = new Promise(() => {}); // streaming-input mode: stdin stays open
async function* promptStream() {
yield { type: 'user', message: { role: 'user', content: 'Count slowly from 1 to 50.' },
parent_tool_use_id: null, session_id: '' };
await keepOpen;
}

const t0 = Date.now();
const q = query({ prompt: promptStream(), options: { model: 'haiku', maxTurns: 1 } });

setTimeout(async () => {
console.log(`[${Date.now() - t0}ms] interrupt() ->`, JSON.stringify(await q.interrupt()));
}, 1000);

for await (const c of q) {
console.log(`[${Date.now() - t0}ms]`, c.type, c.subtype ?? '', c.terminal_reason ?? '');
if (c.type === 'result') break;
}
```

Output from a run just now:

```
[1007ms] interrupt() -> {"still_queued":[]}
[3445ms] system init
[6537ms] result success completed
```

## What happens

Startup takes ~3s here, so the interrupt lands well before `system/init`. It resolves with `{ still_queued: [] }`, nothing is interrupted, and the turn completes normally with `subtype: 'success'` and `terminal_reason: 'completed'`.

A real interrupt — same call, issued after `system/init` — also resolves with `{ still_queued: [] }`, but the turn then ends as `subtype: 'error_during_execution'`, `is_error: true`, `terminal_reason: 'aborted_streaming'`. Identical receipts, opposite outcomes. Four runs, same result.

## Relation to #368, #366, #425

"Nothing happens before init" may well be intended — #368 settled a similar case (first turn dispatched before MCP servers connect) as by design, and waiting for `system/init` is a viable workaround once you know about it. The ask is only that the receipt not report success when nothing was interrupted.

Distinct from #366 (interrupt during thinking → loud `error_during_execution`) and #425 (interrupt mid-API-call → promise never settles). Both of those are observable; this one is silent.

## What would help

Any signal that separates "interrupted something" from "there was nothing to interrupt yet" — a field on the receipt, or a rejection.