Guard OpenCode session-start hook on duplicate session.created

[sanogueralorenzo]

Summary

• only fire the OpenCode session-start hook when session.created switches to a different session id
• keep the existing per-session reset behavior aligned with the lifecycle hook emission
• add a focused hook installation test to lock the generated plugin shape

Why

In the OpenCode plugin, session.created already had a dedupe guard around the in-memory reset state (seenUserMessages, messageStore, currentModel), which means the code already expected the same session id to be observed more than once.

Before this change, session-start was still fired unconditionally even when that guard did not pass. That created an asymmetric path where a duplicate or reactivation-style session.created event for the same session id would:

• skip resetting session-local plugin state
• still emit a second session-start lifecycle event for that same session

That mismatch is not just cosmetic. On the CLI side, session-start is consumed as a real lifecycle event and drives EventSessionStart transitions when session state already exists.

Effect

With this change, OpenCode now treats duplicate session.created events consistently:

• a real session switch still resets tracking state and emits session-start
• a repeated session.created for the current session id only refreshes currentSessionID and does not emit a duplicate lifecycle start

This keeps the plugin behavior aligned with its own dedupe guard and avoids re-firing session-start semantics for an already-tracked session.

Testing

• not run locally (go/mise are not installed in this environment)
• added a hook installation test that asserts the generated plugin keeps session-start inside the currentSessionID !== session.id guard

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.