fix: let pi handle context overflow instead of stopping the loop

[elecnix]

Problem

When context becomes nearly full during an autoresearch run, the extension was proactively calling ctx.abort() and disabling autoresearchMode, stopping the experiment loop instead of letting it continue.

Comparison with PR #41

PR #41 takes a different approach: it keeps the proactive isContextExhausted check but adds an autoCompactResume: true config option to compact and resume instead of stopping.

	PR #41	This PR (#45)
Proactive check	kept (opt-in via autoCompactResume)	removed
Trigger	token-history prediction	overflow error from LLM
Fires when	at start of run_experiment	only when LLM actually overflows
Default	stops (preserves original behavior)	stops (less code)

Why this PR removes the proactive check:

1. It fires before the LLM responds — based on predictions (token history), not actual overflow
2. Predictions are unreliable — the chars/4 heuristic is conservative; large experiment output doesn't mean the LLM will overflow
3. pi already handles this — _checkCompaction detects actual context overflow errors from the LLM, auto-compacts, and retries automatically
4. If the prediction is wrong, you've aborted for nothing — the turn stops, the session reconstructs, and you've added latency for no reason

What This PR Does

Remove the proactive isContextExhausted check entirely:

• Overflow mid-experiment: pi's _checkCompaction detects the overflow error, compacts, retries. The experiment subprocess keeps running (detached) and its result gets logged normally.
• Overflow before experiment starts: same flow — pi compacts, the loop continues.
• State is always persisted to autoresearch.jsonl, so agent_end → agent_start resumes cleanly.

Changes

• Removed: isContextExhausted(), estimateTokensPerIteration(), hasRoomForNextIteration(), CONTEXT_SAFETY_MARGIN (dead code)
• Removed: needsCompaction flag from AutoresearchRuntime (never wired up)
• Removed: the proactive abort block in run_experiment — replaced with a comment
• Kept: recordIterationTokens() and iterationTokenHistory (useful ASI diagnostics)

Why not PR #41's approach?

PR #41's autoCompactResume config is a reasonable alternative if you want to preserve the predictive check for early warning. But:

• The prediction fires before the LLM responds, so it can't know if overflow will actually happen
• A wrong prediction adds latency and complexity for no benefit
• pi's built-in overflow handling already covers the real case

Testing

• node --check extensions/pi-autoresearch/index.ts passes
• Diff: 9 insertions, 32 deletions

[davebcn87]

I want to rework how we handle context on pi-autoresearch. The idea that I have is that every experiment calls programatically /tree so you could run it indefinetely by moving to the first experiment start checkpoint.

This is not yet possible with current pi API. We'll have some implementation side on the pi codebase so that can work.

That will make compaction unnecessary, so don't want to add more complexity as this problem will go away soon.

[elecnix]

@davebcn87 I think I understand what you're saying. If every experiment starts at a checkpoint, the context essentially starts from scratch.

In this case, the solution to context overflow would be to throw away the experiment, instead of stopping the loop.