Expose an API version in /api/info + publish a v1→v2 migration path (routes, prompt payload, events, sessions) #55705

Describe the enhancement you want to request

GET /api/info returns {version, pid, urls, paths, capabilities} — nothing that identifies the HTTP API generation. Since 2.0 the v1 routes are gone entirely (/global/health, /session/..., /question, /pty/...), but from the outside a 2.x server still just says "version": "2.0.29", so clients that gate on semver (>= 1.14.19) happily connect and then fail on every call.

Proposed addition:

{ "version": "2.0.29", "apiVersion": 2, "legacyRoutes": false }

With that, a client can detect the mismatch in one request and show a real error ("this build needs opencode 1.x") instead of failing later with an HTML parse error or a missing message.updated event.

Two related asks that would help third-party drivers:

1. A migration table for the v1 → v2 route/contract changes. The prompt payload changed from {parts: [...]} to {text} and the SSE event model was replaced (message.updated / message.part.updated / session.idle → session.inbox.* / session.execution.* / session.step.*). Right now the only spec is the source diff.

2. A migration path for 1.x sessions. 2.x writes to a separate session_v2 / session_message / session_inbox set of tables in the same opencode.db, so a 1.x client gets 404 for every session created by a 2.x server (and vice versa) — threads look lost even though both versions share one database. A one-way opencode migrate --to 2 would avoid a support wave of "my history disappeared".

Context: found while wiring the T3 Code desktop app (0.0.45, bundles @opencode-ai/sdk@1.15.13) to a 2.x server.