chore(harness-opencode): bump pin 1.18.3 → 1.18.5

[todie]

Closes the investigation opened by #49, where opencode failed with SQLiteError: no such column: replacement_seq.

What actually happened

I misdiagnosed this twice. The evidence settled it — installing 1.18.5 into an isolated prefix and letting each version build a fresh database:

version	fresh-DB migrations	session_context_epoch
1.18.3 (old pin)	35	7 cols — agent, replacement_seq, revision present
1.18.5 (latest)	38	4 cols — 20260622142730_simplify_session_context_epoch drops them

The user's database was 38 migrations / 4 columns — built by 1.18.5, published 2026-07-24, after the 1.18.3 pin (2026-07-16). So the local install had been ahead of the pin and was later rolled back to it. The 1.18.3 binary then queried a column its own newer database no longer had.

The binary was behind the database, not behind the pin — the reverse of my first diagnosis, and the reason reinstalling 1.18.3 didn't help.

Verification

• 1.18.5 returns OK through the gateway on a fresh DB and on the existing one.
• moon check harness-opencode green (9 pass).
• Pin updated in all four places the 3-way gate covers: install.sh, package.json (@opencode-ai/plugin), README.md, and the repo CLAUDE.md upstream-tracking line.

Honest note

The DB reset performed during #49 was avoidable. Bumping to 1.18.5 would have fixed it without discarding the database, since 1.18.5 is what wrote it. Data lost was negligible (2 sessions, 2 messages) and the file is retained at ~/.local/share/opencode/opencode.db.bak-2026-07-25-schema-mismatch, but the reset was the wrong first move and I should have identified the version that produced the schema before touching data.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}