fix(dispatcher): name what an api_error is, so a consumer can tell a failure from an abort

[Juliusolsson05]

Agent Code #1018 review (PR #1044). Agent Code's orchestration lifecycle reads an api_error on an idle session, newer than the latest output, as a failed turn. It could not tell three things apart.

1. Session-less session.error. OpenCode publishes these for instance-wide problems: a SKILL.md, agent, command or plugin file that fails to parse (skill/index.ts, config/agent.ts, config/command.ts, plugin/index.ts). Every session-scoped publish passes a sessionID. The dispatcher's session filter lets these through because there is no id to compare. They stay visible, now marked errorType: 'instance'.
2. User abort. Esc gives MessageAbortedError. Every session error now carries OpenCode's own error name as errorType: APIError, MessageAbortedError, and so on.
3. Delta-buffer overflow. This is not a provider failure, and the turn keeps streaming. It is marked errorType: 'part_overflow'.

Tests

• The recorded usage-limit row also pins errorType: 'APIError'.
• A new recorded abort row, from Agent Code's catalog case b, pins MessageAbortedError.
• The instance case uses the payload exactly as OpenCode's source builds it. A live capture against 1.18.31 was attempted and produced no event; the fixture's provenance explains why.
• Fail-first: all three fail with the dispatcher change reverted.
• npm run check: 22/22 tests pass, and the build and pack checks pass.

🤖 Generated with Claude Code