Test Loop and dedicated Goal ownership on current releases

[ByBrawe]

Goal

Keep the cross-plugin single-autonomous-owner contract covered on a real OpenCode host with an exact released companion version.

What this established

A clean reproduction with OpenCode Loop 0.5.35 + OpenCode Goal 1.3.26 + OpenCode 1.18.21 reproduced the ownership collision on both Ubuntu and Windows: Loop correctly emitted goal-overlap-blocked and persisted no prompt job, but the host command bridge could cancel the in-flight Goal turn and Goal could adopt the Loop command's local agent.

OpenCode Goal 1.3.27 fixes that command-ownership boundary.

Permanent regression canary

This PR now pins the real-host canary to:

• OpenCode Loop 0.5.35 from this checkout
• @bybrawe/opencode-goal@1.3.27 from npm
• current OpenCode CLI

The canary starts a real dedicated /goal, holds its first provider turn open, issues /loop devam et in the same session, and requires:

• Loop emits goal-overlap-blocked
• no Loop job is persisted
• no autonomous Loop provider request starts
• no command bridge request leaks to the model
• the dedicated Goal remains active

The exact Goal pin is intentional: ordinary Loop PR CI stays deterministic. Moving-latest companion compatibility should be monitored separately by a scheduled canary.

Validation

Passed on Ubuntu and Windows with Goal 1.3.27 installed from npm. General Loop CI and the single-file bundle gate also pass.

No production Loop behavior changes are included; this is integration regression coverage and documentation only.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.