fix(opencode): reuse local server for review flows

[oorestisime]

Summary

• try attaching the OpenCode review AI provider to the default local server at 127.0.0.1:4096 before spawning a new opencode serve . this should fix OpenCode AI tab: spawns new opencode serve instead of reusing existing server (port conflict) #513 and OpenCode AI tab: responses not rendering (empty bubbles) #514
• fix the OpenCode plugin's bundled HTML lookup so source-loaded local plugin runs resolve plannotator.html and review-editor.html correctly
• update local sandbox and postinstall command paths to use the documented plugins/ and commands/ directories

The last 2 items were needed to fully test the ./tests/manual/local/sandbox-opencode.sh --keep as otherwise i wasnt hitting the right bundled files. I also had to remove it from my global opencode config.

What I explored

• reproduced the original failure where the review AI path tried to start a second opencode serve and collided with an existing local server
• traced the OpenCode command flow in the sandbox and found a separate local-testing issue: the source-loaded plugin was resolving bundled HTML from the wrong directory, so local runs could fail before opening the UI

Main issue

• When spawning the opencode serve command for a local server it stays open until someone kills it manually. Can confirm this by doing pgrep -af opencode. So on subsequent review commands the server was still running and hence the port conflict.

Final approach

• keep the existing review command UX intact
• keep the fix minimal: attach to the default local OpenCode server if it exists, otherwise spawn a new one
• avoid extra host-specific plumbing and keep only the runtime changes needed for local plugin runs and server reuse

Open questions

• I am not sure if your intention was to always generate a new opencode server. If thats the idea then we should kill the server when the review is done. I feel this might be problematic to be honest since we don't know where the ask might come from nor i am sure if there'a reliable way to kill the server after we are done.
• I am not sure if we should be reusing the existing client as a fallback if it exists either.
• Could make this more reliable and spawn to another port than 4096, but if we dont kill this correctly then we end up with many ports open spammable :D

[backnotprop]

@oorestisime could you do the typecheck fixes? lmk if they are a pain

[oorestisime]

@oorestisime could you do the typecheck fixes? lmk if they are a pain

Yeap done. this was due to changing the opencode client type to be more honest with the sdk.