[Feature] OpenCode 2 (opencode2) support

[stbensonimoh]

Hey, thanks for the plugin. It's been solid on OpenCode v1.

I'm on the OpenCode 2 beta (installed as opencode2), and the plugin does not load there. The V2 plugin API is a hard break: it expects a default export of Plugin.define({ id, setup }), and the current package gets rejected with:

SchemaError: Missing key ["default"]

So opencode2 users lose memory entirely today.

A few things I've verified while porting two other plugins to the V2 API this week, in case they save you time:

• The plugin package must pin @opencode-ai/plugin exactly (I'm on 0.0.0-beta-17728). Caret ranges on prereleases resolve to the wrong build.
• The V2 event stream renamed everything and moved payloads under event.data: session.step.started/ended/failed, session.tool.called/success/failed, shell.created/exited, session.execution.*, session.compaction.*, permission.asked. The old chat.message and permission.ask hooks do not exist there.
• V2 plugins cannot read message history directly. The only access to message content is the messages array handed to ctx.session.hook("context") at dispatch time. Capture and recall need a message cache built from that hook. DCP's v2 port hit the same wall, see Fix five v2-port bugs: nudges never fire, /dcp-compress crashes on every path Opencode-DCP/opencode-dynamic-context-pruning#605.
• Two beta quirks worth knowing: the server loads local plugin entries twice (handlers need dedupe), and plugin cleanup must not await the event stream. Abort does not close it, and awaiting it hangs the server on every reload.

I'd propose an additive entrypoint rather than flipping the default, so existing V1 users keep working:

// package.json
"exports": {
  ".": "./dist/index.js",        // unchanged, V1
  "./v2": "./dist/v2/index.js"   // new, opencode2
}

V2 users would configure "plugins": ["opencode-supermemory/v2"]. The service layer in src/services/* should port mostly unchanged; the v2 work is a new entrypoint plus a message cache, tool registration via ctx.tool.transform, and mapping capture to the new session events. PR #70's direction (native compaction lifecycle) lines up nicely with the v2 compaction events, which is convenient.

I looked at the alternatives. A private fork works but drifts from your client changes, and waiting for the API to stabilize leaves opencode2 users without memory indefinitely. Neither is better than an upstream port.

Before I start building: is there in-flight opencode2 work I'm missing? I run opencode2 daily and can test any branch immediately. If this plan works for you, I'm happy to open a PR.