Native V8 array-length crash during active tool-heavy turns and session resume

### Describe the bug

The packaged Linux x64 native binary aborts inside V8 during active, tool-heavy turns as well as while resuming conversations.

The original report attributed this to several concurrent resumes. Further testing disproved that: Herdr automatic restoration was disabled, failed panes were cleared, and an already-running conversation crashed mid-turn while displaying:

```text
Reviewing brief clarity · 29.4 KiB
# Fatal error in , line 0
# Fatal JavaScript invalid array length 0
```

A second active conversation failed similarly while displaying `Shipping Lakebase refactor · 53.7 KiB`. Both ended with SIGILL. These were normal active turns, not startup or bulk restore.

The fatal string maps to V8's `Accessors::ArrayLengthSetter`, where `JSArray::SetLength(..., 0)` returned an exception and V8 called `FATAL`:

https://github.com/v8/v8/blob/main/src/builtins/accessors.cc#L210-L214

### Affected version

GitHub Copilot CLI 1.0.70

### Steps to reproduce the behavior

A minimal deterministic reproduction is not yet available. The recurring observed sequence is:

1. Start or resume a Copilot conversation.
2. Run a long, tool-heavy workflow with many subagents.
3. Start another turn.
4. While Copilot is actively streaming/reviewing the response, the native process aborts with `Fatal JavaScript invalid array length 0` and SIGILL.

Two affected conversation histories were approximately:

- 14.1 MB / 2,482 events / 929 completed tool calls / 23 completed subagents
- 21.3 MB / 3,959 events / approximately 1,500 completed tool calls / 24 started subagents

The final persisted event in each is `assistant.turn_start` without a matching `assistant.turn_end`, confirming the failure occurred mid-turn.

### Expected behavior

Long or tool-heavy conversations should continue normally. If an internal array operation fails, the CLI should surface a recoverable JavaScript error rather than aborting the native process.

### Additional context

- OS: Ubuntu 24.04 under WSL2, Linux `6.6.114.1-microsoft-standard-WSL2`, x86_64
- Terminal: Windows Terminal -> Herdr PTYs
- Shell: zsh
- Memory after the latest crash: 31 GiB total, 28 GiB available, no swap in use
- Copilot's embedded runtime reports Node.js `v24.16.0`
- Kernel logs show repeated SIGILL failures at the same native address
- `app.js` and `index.js` checksums match between the npm platform package and Copilot's update cache
- The npm loader's subsequent `no platform package found` message is misleading; the platform package launched successfully and its child process terminated by signal
- Reinstalling npm replaces 1.0.70 with the same 1.0.70 and does not resolve the failure
- Herdr's `resume_agents_on_restore` setting is not required to trigger this
- Running the packaged JavaScript entrypoint under system Node.js `v24.11.1` passes startup/version and interactive Herdr smoke tests. I am testing this as a temporary workaround, but it has not yet had the same long-duration workload.

先从打包的 JavaScript 入口 app.js 和 index.js 开始，然后比较它们在已记录的系统 Node.js workaround 下的行为。如果可能，复现一次漫长且大量使用工具的 active-turn workflow，并捕获原生故障。完成的标准是 workload 不再因 V8 invalid-array-length SIGILL 而中止，或者 CLI 改为显示一个可恢复的错误。

由索引模型根据 Issue 内容生成。